I tried checking the behavior of calls and recordings when the operator's network has a momentary interruption in Amazon Connect
This page has been translated by machine translation. View original
Introduction
While using Amazon Connect's softphone, I was curious about what would happen to a call if the operator's Wi-Fi or network momentarily dropped.
The specific points I wanted to verify were as follows.
- If the operator's network briefly disconnects during a call, does the call drop immediately?
- After audio becomes inaudible, does it automatically resume after the network recovers?
- How is recording and transcription handled during that period?
This time, I reviewed what could be confirmed in Amazon Connect's official documentation, while also temporarily disconnecting the operator's Wi-Fi during an actual softphone call to observe the behavior.
Note that this article summarizes results confirmed in a specific test environment. Behavior may vary depending on the Wi-Fi disconnection duration, browser, device, network equipment, and Amazon Connect configuration.
Also, this article covers verification for softphone usage, and behavior when using a desk phone is out of scope.
Conclusion First
In this verification, there were cases where temporarily disconnecting the operator's Wi-Fi during Amazon Connect softphone usage did not immediately drop the entire call.
On the other hand, I also observed behavior that appeared to show the operator unable to hear the other party's audio during the Wi-Fi disconnection, and the operator's audio appearing not to reach Amazon Connect.
To summarize, rather than simply "whether the call drops or not," it seems easier to understand by looking at which side's audio appeared to be reaching Amazon Connect during the brief disconnection.
Within the scope confirmed this time, in cases where the other party's audio appeared to be reaching Amazon Connect, the other party's speech was reflected in recordings and transcriptions even though the operator was temporarily unable to hear it. On the other hand, in cases where the operator's audio appeared not to be reaching Amazon Connect, no recording or transcription of the operator's audio remained for that segment.
However, it seems better not to assume that audio will always resume after network recovery. While this verification confirmed cases where recovery occurred, recovery is not guaranteed, and in actual operations there will likely be situations that should be treated as call drops or one-way audio.
What I Confirmed in the Official Documentation
The audio path between the browser and Amazon Connect becomes critical when using softphone
In Amazon Connect's Contact Control Panel (hereinafter CCP), when an agent logs in, connections are established to various endpoints for signaling, media, and web artifacts. When using softphone, the media connection between the operator's browser and Amazon Connect directly affects call quality.
In the official documentation, regarding inbound calls, it is explained that customer calls are received at the Amazon Connect endpoint, and when the agent responds, a media connection is established from Amazon Connect to the agent.
Regarding the behavior when the browser window is closed, the following explanation is provided.
the call remains connected
The call itself remains connected.
https://docs.aws.amazon.com/connect/latest/adminguide/ccp-connectivity.html
The same section also explains that even if the browser is reopened and the agent logs back in, the media connection cannot be re-established. In other words, if the audio path on the browser side is lost, even if the call itself remains, the original audio path is not guaranteed to return.
However, this explanation describes behavior for the case of "closing the browser window running the CCP." It does not explain the detailed reconnection conditions for Wi-Fi brief disconnections themselves. Therefore, regarding Wi-Fi brief disconnections, while this verification confirmed cases where audio resumed after recovery, it seems better to avoid expecting a return to the original call state at all times.
Recording separates audio channels for the agent side and customer side
Amazon Connect's recording specifications state that during interactions with agents, you can choose to record the customer, the agent, or both. It is also explained that during agent interactions, the agent's audio is saved to the right channel, and incoming audio such as customers and conference participants is saved to the left channel.
With these specifications in mind, when reviewing recordings, it seems important to look not only at "whether the operator could hear" but also at "which side's audio was reaching Amazon Connect."
On the other hand, based solely on the documentation reviewed this time, it is not possible to definitively determine how missing segments during a network brief disconnection are handled for transcription. Therefore, in this article, the behavior of transcription is treated as "results that appeared that way in this particular test environment."
DisconnectDetails is useful for investigating call drops
When a call disconnection occurs, the DisconnectDetails in the contact record is useful for investigation.
The official documentation explains that AGENT_CONNECTIVITY_ISSUE or AGENT_DEVICE_ISSUE may be set as detection reasons in PotentialDisconnectIssue. AGENT_CONNECTIVITY_ISSUE suggests that there was a network connectivity issue between the agent's device and Amazon Connect that led to the call disconnection.
However, DisconnectDetails is information about call disconnections, and it may not be possible to determine solely from this whether an event occurred as a temporary silence or one-way audio without the call itself being disconnected.
What I Actually Tried
This time, during an Amazon Connect softphone call, I intentionally temporarily disconnected the operator's Wi-Fi and then restored it.
The verification confirmed the following 2 patterns.
- Disconnecting the operator's Wi-Fi while the other party is continuously speaking
- Disconnecting the operator's Wi-Fi while the operator is continuously speaking
Here, the call counterpart is referred to as the "other party," and the user operating Amazon Connect's CCP is referred to as the "operator."
Case 1: Disconnecting the operator's Wi-Fi while the other party is speaking
First, while the other party was continuously speaking, I disconnected the operator's Wi-Fi and then restored it.
During the Wi-Fi disconnection, the operator could not hear the other party's audio.
After Wi-Fi recovery, the call audio became audible again and the call could continue.
When reviewing the recording and transcription, it appeared that the other party's audio was reflected in both the recording and transcription even during the segment when the operator could not hear the other party.
From this result, at least in this verification, it is considered that even if the operator's receiving audio path is temporarily lost, there are cases where the other party's audio is reflected in recordings and transcriptions when that audio was reaching Amazon Connect.
Case 2: Disconnecting the operator's Wi-Fi while the operator is speaking
Next, while the operator was continuously speaking, I disconnected the operator's Wi-Fi and then restored it.
In this case as well, during the Wi-Fi disconnection, the call audio could not be handled normally.
After Wi-Fi recovery, the call could resume.
On the other hand, when reviewing the recording and transcription, the operator's audio during the segment when the Wi-Fi was disconnected was not retained.
From this result, it is considered that for segments where the operator's network was disconnected and the operator's audio appeared not to be reaching Amazon Connect, there are cases where that audio is not reflected in recordings or transcriptions.
Thoughts from the Verification Results
The entire call is not necessarily dropped immediately
In this verification, there were cases where even temporarily disconnecting the operator's Wi-Fi did not immediately drop the entire call. This result appears to be consistent with the official documentation's explanation that the customer's call and the agent's media connection are handled as separate paths.
However, what is explicitly stated in the official documentation covers the explanation of connections when the browser is closed and for each call type. The detailed conditions regarding how long a Wi-Fi disconnection can last before recovery, or at what point a call drop occurs, cannot be confirmed.
Therefore, in actual operations, it seems better not to assume "a brief disconnection will always recover," but rather design with the premise that recovery may occur but is not guaranteed.
It is important to verify which audio was reaching Amazon Connect when reviewing recordings and transcriptions
In this verification, even during segments where the operator could not hear the other party's audio, the other party's audio appeared to remain in the recording.
This is easier to understand by considering that whether audio reached the operator's browser and whether the other party's audio reached Amazon Connect are not necessarily the same thing.
Amazon Connect's recording specifications store agent audio and customer audio in separate stereo channels during agent interactions. Therefore, when reviewing recordings, looking at which channel retains audio provides a clue to distinguish which side's audio was reaching Amazon Connect.
Regarding transcription as well, in this verification, speech from the side that appeared to have reached Amazon Connect was reflected, while speech from the side that appeared not to have reached Amazon Connect was not reflected.
It is better not to judge based solely on "whether it was audible"
From these results, when reviewing recordings and transcriptions, it seems better not to judge based solely on whether the operator could hear at the time.
For troubleshooting, the following perspectives make it easier to organize findings.
- Was the other party's audio audible to the operator?
- Was the operator's audio audible to the other party?
- Does audio remain in the agent-side channel of the recording?
- Does audio remain in the customer-side channel of the recording?
- Which party's speech is missing in the transcription?
- Was the target call actually disconnected, or was it one-way audio or temporary silence?
By examining these separately, events that are difficult to understand just by looking at "whether the call dropped" become easier to organize.
Assume a Stable Network for Softphone Operations
Amazon Connect's network troubleshooting documentation advises using fixed Ethernet rather than Wi-Fi wherever possible.
Use fixed Ethernet (not Wi-Fi) wherever possible.
Use fixed Ethernet rather than Wi-Fi wherever possible.
https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/network-ts.html
In this verification as well, it was confirmed that a brief Wi-Fi disconnection on the operator's side can affect the audio path, at least temporarily.
Since softphone handles real-time audio through a browser, for stable operations, it seems better to assume a wired connection wherever possible.
Summary
This time, I temporarily disconnected the operator's Wi-Fi during an Amazon Connect softphone call and confirmed the behavior of the call, recording, and transcription.
In this verification, there were cases where the entire call was not immediately dropped even after a brief Wi-Fi disconnection. However, since audio resumption after recovery is not guaranteed, it seems better to account for the possibility of call drops or one-way audio in actual operations.
For reviewing recordings and transcriptions, rather than judging solely based on whether the operator could hear at the time, it is easier to organize findings by looking at which side's audio appeared to be reaching Amazon Connect.
