you need to implement a Ping-Pong messaging to keep the session alive.
I believe that you can just respond to a received Genesys "WebSocket Heartbeat" message (~ every 8 seconds) with some random data to prove that your receiver is still alive.
If you implement sending a "ping" e.g. every 5 seconds, you will not receive a "WebSocket Heartbeat" anymore.
If you do not prove that you are alive, Genesys will close the session to save AWS consumption costs.
Please have a try and let us know.
Original Message:
Sent: 08-01-2025 09:40
From: Naoki Ono
Subject: Intermittent WebSocket Disconnections When Subscribing to Call Events in Genesys Cloud
I am using Windows.
At this point, I am unsure if the issue is related to the client terminal, the network, or the Genesys Cloud application itself.
Do you have any useful information or advice that could help identify the cause?
------------------------------
Naoki Ono
Original Message:
Sent: 08-01-2025 09:06
From: Amit Abdul
Subject: Intermittent WebSocket Disconnections When Subscribing to Call Events in Genesys Cloud
I had a similar issue. The key is with making sure that you keep the web socket thread running and do not let OS to suspend it. This is especially something we ran into when using Windows. Are you running in a browser or nginx?
------------------------------
Amit Abdul
Original Message:
Sent: 08-01-2025 01:09
From: Naoki Ono
Subject: Intermittent WebSocket Disconnections When Subscribing to Call Events in Genesys Cloud
I am experiencing an issue with WebSocket connections when subscribing to call events in Genesys Cloud from an external application.
Below are the details of the issue:
★Issue Description
I am utilizing the following program to establish a WebSocket connection and subscribe to Genesys Cloud notification topics:
--------------------------------------------------------------------------------------
var channel = subscriptionUtil.MakeSubscriptionChannel();
subscriptionUtil.AddTopicToSubscription(loginUser);
var uri = new Uri(channel.ConnectUri);
using (var clientWebSocket = new ClientWebSocket())
var segment = new ArraySegment<byte>(buffer);
var result = await clientWebSocket.ReceiveAsync(segment, cancellationToken);
if (result.MessageType == WebSocketMessageType.Close)
{
logger.Info("WebSocket close message received from Genesys Cloud server. Exit loop");
break;
}
--------------------------------------------------------------------------------------
I expect the WebSocket connection to stay alive continuously for up to 24 hours.
However, in reality, the connection is unexpectedly closed at a high frequency, approximately every two hours,
even though heartbeats appear to be exchanged without any issues.
★Relevant Logs
--------------------------------------------------------------------------------------
INFO Notification received. { MessageType: Text, Count: 82, EndOfMessage: True }
INFO {"topicName": "channel.metadata", "eventBody": {"message": "WebSocket Heartbeat"}}
DEBUG GetNotification start. message: {"topicName": "channel.metadata", "eventBody": {"message": "WebSocket Heartbeat"}}
DEBUG Notification is neither presence notification nor call notification
INFO Notification received. { MessageType: Close, Count: 0, EndOfMessage: True }
INFO WebSocket close message received from Genesys Cloud server. Exit loop
INFO Entered finally block, going to close WebSocket connection
INFO Closed WebSocket connection successfully. state: Closed
--------------------------------------------------------------------------------------
★Question
Could you please explain the possible reasons for these intermittent WebSocket disconnections even though heartbeat messages are being received regularly?
Is there a limitation regarding WebSocket session duration or inactivity timeouts for notification channels in Genesys Cloud?
Is there any recommended practice for keeping the WebSocket connection alive for longer periods?
Any insight into the Genesys Cloud WebSocket session mechanism or potential causes for these disconnections would be highly appreciated.
#PlatformAPI
#PlatformSDK
#WebMessaging
------------------------------
Naoki Ono
------------------------------