User → agent audio not flowing via chan_websocket external media (bridge stays in simple_bridge, only agent → user works)

[tecnomanu]

Summary

Outbound calls through Asterisk ARI + chan_websocket external media establish correctly and the agent's greeting reaches the user, but user audio never reaches Dograh — VAD logs only show "no audio while speaking". After extensive Asterisk-side debugging I'm fairly confident this is a simple_bridge interaction issue specific to chan_websocket, but I'd appreciate guidance on the recommended workaround / whether Dograh plans to address this.

Setup

• Dograh: latest, deployed via the dokploy-dograh installer (recent build, includes PR fix(ari): pre-register ext channel id and defer bridge to its StasisS… #284)
• Asterisk: 20.19.0 (latest 20.x LTS, official build from source with chan_websocket and app_amd enabled)
• Telephony provider config: Asterisk ARI, ws_client_name = dograh, app_name = clau
• Trunk: SIP/PJSIP outbound to an upstream carrier (Astervoip), ulaw negotiated
• Network: VPS, Asterisk in network_mode: host, Dograh containers reach Asterisk via host.docker.internal:8088. No NAT between the two services.
• All modules running: chan_websocket.so, res_http_websocket.so, bridge_simple.so, bridge_softmix.so — no warnings/errors in Asterisk logs.

Symptom

1. Outbound call originates correctly through Dograh UI.
2. PJSIP/trunk-astervoip-* and WebSocket/dograh/* channels are created and joined into a single bridge.
3. Agent's greeting (TTS → WebSocket → bridge → PJSIP → user phone) works fine — user hears the agent.
4. User speaks → audio reaches Asterisk's PJSIP channel (verified via pjsip show channelstats RTP Receive Count increasing at expected rate) → but no audio ever reaches Dograh's pipeline. Dograh VAD only logs no audio received while speaking.

So agent → user works, user → agent does not.

Bridge inspection (during an active call)

$ asterisk -rx "bridge show all"
Bridge-ID                            Name                    Chans Type    Technology      Duration
31ef7bb3-e51b-4a47-8385-8bb7ea536e7d bridge-1779076370.0         2 stasis  simple_bridge   00:01:09

$ asterisk -rx "pjsip show channelstats"
                                 ...........Receive......... .........Transmit..........
 BridgeId ChannelId    UpTime    Codec   Count    Lost Pct   Count    Lost Pct
 31ef7bb3 trunk-astervoip-00000000  01:46  ulaw  1121      35    3     5050     0    0

Receive count grows ~50pps while user speaks → audio reaches PJSIP. The bridge stays in simple_bridge for the whole call.

What I've already tried (Asterisk-side, no change in behavior)

1. rtp_keepalive=5 + rtp_timeout=60 on the trunk endpoint — per the Asterisk community thread suggesting this fixes simple_bridge + external media one-way audio. Confirmed loaded via pjsip show endpoint trunk-astervoip. No effect.

2. set_var=JITTERBUFFER(adaptive)=default on the trunk endpoint — to install a framehook on the PJSIP channel and break native bridging eligibility. Confirmed loaded. Bridge still selects simple_bridge. No effect.

3. Codec fronting (alaw before ulaw) — to force transcoding and thus softmix. Astervoip ignored alaw and kept ulaw. No effect.

Conclusive test that isolates the bug to chan_websocket

I have a separate setup on the exact same Asterisk container (same binary, same PJSIP config, same trunk, same NAT) that uses chan_audiosocket instead of chan_websocket for external media. With AudioSocket, bidirectional audio works perfectly — user speech is transcribed, agent responds in real time:

[user]  «pues ahora bien, pero»
[clau]  «Sí, perfecto. Te escucho claro.»

So the issue is specifically the chan_websocket + 2-channel simple_bridge combination.

Hypothesis

Asterisk's simple_bridge selection for 2-channel bridges seems to have an asymmetry when one of the channels is chan_websocket: frames flow from WebSocket → PJSIP (agent greeting reaches user) but not from PJSIP → WebSocket (user audio never reaches Dograh).

The classic workaround mentioned in the Asterisk community is to add a 3rd silent channel to the bridge so it gets promoted to softmix, which doesn't have the issue. But Dograh creates the bridge with {type: "mixing"} and only ever adds the caller + ext-media channels, so it always ends up as simple_bridge:

api/services/telephony/ari_manager.py#L486-L508

Questions

1. Is this a known issue? Is there a recommended Asterisk version / config that avoids it?
2. Would Dograh be open to adding a silent 3rd channel to force softmix as a built-in workaround?
3. Or is there a Dograh-side flag / ARI param I'm missing that changes how the bridge is created?

Happy to provide more logs, packet captures, or run any test that helps narrow this down. Thanks for the great project.