Jump to: navigation, search


Section: settings
Default Value: major
Valid Values: none, major, major2, typing, all
Changes Take Effect: Immediately
Introduced: (Restricted); 8.5.301.06 (Generally Available)
Modified: 8.5.310.09

Specifies which notifications count as async chat session activity for the purpose of inactivity control.

  • all: All user notifications are included (custom, push URL, typing on/off, update nickname).
  • major: Only major notifications are included (push URL, file uploaded, file deleted).
  • major2: Extends the major value with custom notifications.
  • none: All notifications are excluded.
  • typing: Only major and "typing on" notifications are included.


Section: settings
Default Value: 3600
Valid Values: Any integer from 1-1728000
Changes Take Effect: Immediately
Introduced: (Restricted); 8.5.301.06 (Generally Available)

Specifies, in seconds, a timeout that starts after "async-idle-alert" (enabled only for async chat sessions). If any qualifying activity occurs, (see "async-idle-alert" for a description of what qualifies as activity), the timeout stops and "async-idle-alert" timer is reset. If no qualifying activity is detected during this timeout, Chat Server:

  • Sends the IDLE_CONTROL_CLOSE notice with a message specified by the value of the "message-close" option (in the section [inactivity-control]).
  • Closes the chat session.


Section: settings
Default Value: 86400
Valid Values: Any integer from 1-1728000
Changes Take Effect: Immediately
Introduced: (Restricted); 8.5.301.06 (Generally Available)

Specifies an inactivity alert timeout (in seconds) which will be enabled only for async chat sessions. The inactivity timeout is set (or reset) for a session after any of the following activities: agent joined or left, any chat participant sent a message or a notice (as defined by "async-idle-notices"). If no qualifying activity is detected during this timeout, Chat Server:

  • Sends the IDLE_CONTROL_ALERT notice with a message specified by the value of the "message-alert" option (in the section [inactivity-control]).
  • Updates the interaction properties: GCTI_Chat_AsyncStatus=3 and GCTI_Chat_AsyncCheckAt={time to check interaction at}.
  • Starts the timeout specified by the value of the "async-idle-close" option.


Section: settings
Default Value: 300
Valid Values: Any integer from 1-1728000
Changes Take Effect: Immediately
Introduced: (Restricted); 8.5.301.06 (Generally Available)
Modified: 8.5.310.09

Specifies timeout (in seconds) after which Chat Server sends ping notification for push-flex connected client. If no request from the client is submitted within the next "flex-push-timeout", Chat Server activates flex-disconnect-timeout. Inactivity is defined as the absence of protocol requests, not the absence of messages

Async Requirements


In order to enable async chat capabilities, the following must be provisioned:

  • During a chat session creation, special key-value pairs must be provided:
    • GCTI_Chat_AsyncMode=true. This enables a special processing in Chat Server and Agent Desktop, and can also be used in the workflow logic.
    • Both push_notification_deviceid and push_notification_type, as described in Chat API Version 2 with CometD. This forces the Chat Server to use flex-push-timeout instead of flex-disconnect-timeout for the async chat session. The corresponding push notification functionality in GMS must also be configured.
  • Chat Server (version 8.5.301.06 and higher required) configuration must be reviewed for the following configuration options:
    • To prevent the chat session from being closed when a mobile application disconnects with GMS, set the value of the flex-push-timeout option to a larger value (for example, 86400 seconds). If there is no protocol activity from a mobile application for the duration of this timeout, Chat Server checks with GMS to see if a connection with a mobile application is still alive. If GMS does not confirm the liveness of a connection, Chat Server sets the timer again and, when the timeout expires, removes a customer from the chat session if no protocol activity is detected.
    • Consider adjusting (only if needed) async-idle-alert , async-idle-close , async-idle-notices . Default values of these options enable async inactivity control monitoring for async chat sessions. The value of option async-idle-notices also defines the condition when GCTI_Chat_AsyncStatus is updated to a value of "2".

Async inactivity control

  • Async inactivity control is different from regular inactivity control (specified in configuration of section [inactivity-control]) in a way that it does not require the presence of an agent in the chat session.
  • Activity in inactivity control means any activity in the chat session that is visible to all participants and that is not generated by bot participants.
  • It is not recommended you enable regular inactivity control (section [inactivity-control]) for Chat Server which handles async chat sessions, as it contradicts with the nature of long chat sessions.
  • async-idle-alert/close reuses the message-alert/close options from the section [inactivity-control] for the notification.

Minimum release requirements

Workspace Desktop Edition

Workspace Desktop Edition (version and higher) provides:

  • Additional Place Chat On Hold button (configuration option chat.on-hold-queue) which allows an agent to return the chat session into the workflow (in other words, put into a dormant state) where it can await customer activity.
  • The possibility to open the active chat from the workbin and contact history windows.

Genesys Mobile Services (GMS)

The mobile or web (in other words, Widget) application, which implements a chat client for a customer, must operate with GMS using Chat API V2 with CometD and enable push notification functionality (either mobile or custom http). This keeps the chat session running for as long as it is needed. GMS version or higher is required.

Historical reporting

There are minimum release requirements for multiple additional components to enable historical reporting on async chat sessions. For full details, see the Prerequisites table at Integrating Chat Server with Genesys Historical Reporting.

Async chat states

GCTI_Chat_AsyncStatus is an integer and any positive value may be used to trigger the workflow to route an interaction to an agent. The following values are possible:

Value Description
-2 Set when a chat session is placed on hold or into a dormant state (in other words, placed into the workbin or queue by an agent).
-1 Set when an agent is processing a chat session.
0 Undefined value (value is not used).
1 Signifies a newly created chat session.
2 Set when a customer posted a reply (sent a message) into a chat session while there were no agents in that chat session.
3 Set when async inactivity control timeout expires (meaning Chat Server will soon close the chat session).
4 Set when an agent desktop abnormally disconnects from the Chat Server (in other words, in case of accidental exits).
5 Set when the agent transfers the chat interaction by placing it into a queue.

Additional information

  • Workflow with a special processing must be deployed (see the sample workflow provided in Deployment). It must evaluate the following interaction properties:
    • GCTI_Chat_AsyncCheckAt contains a timestamp when an interaction must be checked. This property must be used to detect "stuck" interactions in workflow which happens under abnormal situations (for example, in a case when Chat Server has stopped, and a chat session was never restored on another instance of Chat Server).
  • Async chat sessions can be processed in the same way as non-async chat sessions. Async chat simply extends the functionality for chat session processing.
  • In Async mode (in other words when CometD is used with GMS, and the rate of messages in a single chat session is low), a single instance of Chat Server is capable to support a greater number (up to 5000) of concurrent chat sessions. However, the Chat Server limitation of concurrent connections (4K on Windows and 32K on Linux) must be taken into account when planning your deployment. When calculating the number of total expected connections for web or mobile chat, consider the following:
    • Every agent desktop and every chat bot require a separate persistent connection to chat session. For agents, multiply it by the maximum possible capacity of agents.
    • Additionally, supervisor monitoring requires a separate persistent connection.
    • Client (in other words, consumer-facing) operations do not keep a persistent connection with Chat Server. The connection is only established when the consumer sends the request with a message or notice, or when Chat Widget requests periodic pull transcript updates (which is applicable only in non-CometD mode in GMS).Once the request is complete, the connection is immediately closed.
This page was last edited on January 9, 2020, at 13:16.


Comment on this article:

blog comments powered by Disqus