The Vocera XMPP Adapter manages stored data in Vocera Platform datasets to represent conversations and resources. An XMPP cache database stores the roster for the mobile devices. Using these datasets, conditions and rules are configured to interact with other endpoints that are not XMPP-enabled. Vocera XMPP Adapter rules are configured to send conversation, message, and presence information to the Vocera XMPP Adapter when this information is created by an external resource.

XMPP issues often relate to client behavior; see Vocera Vina iOS 6.0.0, Vocera Vina Android 6.0.0, and Vocera Platform 6.4.0 for additional information.

This section summarizes the new features in this release.

This section provides information about fixes and improvements to the Vocera XMPP Adapter product.

This section provides information about known product defects and limitations in the current release.

• The user's presence is not updated to "Available" after the defined duration expires. (PFM-9544)

  Workaround: When XMPP is restarted, all clients that were in DND presence will be reset to Available when they reconnect.

• Presence information is inconsistently reported if you create a user with the same login as a deleted user. (PFM-11097)

• If you create a user with the same login as a previously deleted user, the new user can log into the iOS version of the Unified Client but is automatically logged out after approximately 10 seconds. (PFM-11102)

• If you create a new user with the same login as a previously deleted user, neither the recreated user's device nor the recreated user's XMPP identity are registered with the system correctly. (PFM-11109)

• When you successfully delete a user, the audit log incorrectly reports a "Failed to process event" statement for every message the deleted user has previously sent. Performance may be adversely impacted if the deleted user has many messages. (PFM-11108)

• Deleting a user with many (approximately 4,000) combined messages, conversations, and assignments may delay the delivery of a critical alarm or alert by approximately 40 seconds. (PFM-11115)

• Failing over to a different node causes data that the XMPP adapter has acknowledged, but not processed, to be lost. (XMPP-474, PFM-14822)

  Workaround: Restart the XMPP adapter to rebuild the XMPP cache and create the missing identities.

• Sending a request to cancel a "coverage request" may result in one or more participants not receiving the cancellation. (XMPP-472, PFM-15376)

• Double notification of template creation will be sent to a user if they are logged into both Vina iOS/Android and Vina Web. (XMPP-471, PFM-16172)

• If a person drops a connection during a 1/1 conversation, they will receive all of their presence notifications when they reconnect to the conversation. (XMPP-109, PFM-11823)

• Updating the pillow_number of a bed in an alert may cause XMPP to deadlock. (XMPP-39, PFM-14310)

  Workaround: Pre-populate the pillow_number for every bed to the value that will be reported by alerts. This will prevent the alert creation from generating a Bed subscription message, making it extremely unlikely this particular deadlock will occur.

• The Facility and Unit names are not updated in the Vina application after being updated in Vina Web. (XMPP-38, PFM-14873)

  Workaround: Restart the XMPP adapter after updating the Facility or Unit name in Vina Web,

• If two incoming calls come in at the same moment, the second call will be reported as declined instead of missed. (XMPP-32, PFM-15890)

• If Postgres is interrupted while starting the XMPP adapter, the XMPP cache connection pool will be in a prolonged bad state. (XMPP-24, PFM-15945)

  Workaround: Contact the Support Desk to run a corrective script.

• A race condition exists where badge users may receive a Mass Alert twice. (XMPP-645)