Resolved Issues
|
Incident |
Resolved Issue |
|---|---|
|
STNG-7815 |
Supervisors could not access call recordings of users belonging to different access groups, despite confirmation that the recordings existed and appropriate permissions were in place. |
|
STNG-7799 |
Record on Demand (ROD) sessions of video or screen-sharing calls produced audio-only recordings and were marked as audio-only media type in the Interactions page. |
|
STNG-7383 |
Alarms used inconsistent identities and varied naming across sources, making filtering unreliable. |
|
STNG-7346 |
In some cases, calls stayed in "Pending" status after the media was uploaded and acknowledged, requiring manual cleanup. |
|
STNG-6329 |
Some calls appeared to be missing JSON metadata while an .opus file existed in storage, suggesting lost data. However, it was detected that this occurred when an invitee never joined a conference or when a call was deleted (manually or by retention) and the deletion did not remove the already-created audio file from storage. |
|
STNG-5972 |
Per-node and total CPU utilization alerts could fire repeatedly in rapid succession due to transient spikes, creating noisy “SFB Node CPU Utilization Error/Alert” and “SFB Total CPU Utilization Error” events. |
|
STNG-7800 |
Although a Recording Profile incoming calls’ filter was set up to allow (record) only calls from a certain number, calls from other numbers were not blocked in certain forwarded PSTN scenarios (e.g., via external call center flows). This resulted in unintended recordings. |