Compliance recording and silence on Direct Routing that are on-hold

On a Compliance Recording setup, we have a problem with music-on-hold and Direct Routing calls via an Audiocodes SBC.

There are 4 participants in the call, according to the callRecord:

• Recorded user
• External party
• Policy Recording bot
• Conferencing Virtual Assistant

With the compliance policy in place, when the Recorded user puts an External party on hold, the External party only hears silence and no music-on-hold. If the compliance policy is removed, the External party receives music-on-hold.

Looking at the messages posted to the "/api/calling/" endpoint, only the Recorded user, External party and Recording bot appear as participants during the call. I don't know what the "Conferencing Virtual Assistant" is.

In the "request" value of the log created by ICommunicationsClient::LogAndCreateResponse(), the "direction" field changes from "sendReceive" to "inactive" when the call is put on hold.

Portion of Recorded user entry after putting call on hold:
{
"@odata.type": "#microsoft.graph.participant",
"mediaStreams": [
{
"@odata.type": "#microsoft.graph.mediaStream",
"mediaType": "audio",
"label": "main-audio",
"sourceId": "15",
"direction": "inactive",
"serverMuted": false
}
],

I thought perhaps the Recording bot needs to respond and set the direction to "inactive" somehow as well, but the policy recording bot is set to "receiveOnly".

Portion of bot entry:
{
"@odata.type": "#microsoft.graph.participant",
"mediaStreams": [
{
"@odata.type": "#microsoft.graph.mediaStream",
"mediaType": "audio",
"label": "main-audio",
"sourceId": "1",
"direction": "receiveOnly",
"serverMuted": false
},

Shouldn't this be enough to indicate the External party should be hearing music-on-hold (nobody can transmit audio to the External party). The bot never sends audio.

Is it possible the music-on-hold is coming from the SBC and the presence of the recording bot is confusing the SBC into thinking there are still 2 parties talking, and that it should not send music-on-hold?

Why is there no music-on-hold when the recording bot is involved?
What does the Policy Recording bot need to do to fix this, or is it a problem at Microsoft or at the SBC?

Start by reviewing the /api/calling/ messages and the request value logged by ICommunicationsClient::LogAndCreateResponse(). Compare participant mediaStream direction changes when the recorded user is placed on hold, including the Policy Recording bot and Conferencing Virtual Assistant entries. Done means identifying whether the silence is caused by the recording bot, Microsoft Graph communications behavior, or the Audiocodes SBC, with a confirmed remediation path.