WebRTC · Asterisk

WebRTC call does not bridge to the ready agent

A browser call starts but does not join the intended ready-agent conference.

Source and affected scope

Configuring Asterisk for WebRTC Clients

Source date: Not stated in source
Source checked: 2026-11-07
Reported version: Version-specific behavior; inspect the installed release
Guide updated: 2026-11-07

Registered browser phone does not necessarily have a connected media path or agent bridge.

Before you start

Authorized isolated lab and consenting test participants; record server/build and before-state.
Never publish real phone numbers, network addresses, credentials, call audio or database rows.

Diagnose the reported problem

Step 1Inspect the actual endpoint and browser state
Open the approved browser’s WebRTC internals for the test connection (Chrome: chrome://webrtc-internals); examine selected candidate pair, ICE and DTLS state and packet counters. No browser page proves the other leg by itself.
On the PBX inspect the known endpoint and current channels; correlate only the synthetic station and test time.
Before you use it
Run only on an authorized isolated lab or approved read-only diagnostic session; substitute placeholders. Preserve sensitive data privately.
Inspect the actual endpoint and browser state
```
asterisk -rx 'pjsip show endpoint TEST_ENDPOINT'asterisk -rx 'core show channels concise'
```
Reader-run example · not executed for this guide
This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.
Success looks like
A selected working ICE pair, established DTLS and increasing packet counters are supporting media evidence, not proof of an agent/customer bridge.
Stop if
No candidate or failed DTLS: inspect certificate trust, WebSocket, ICE and reachable media first; stop before guessing at conference settings.
Expected observation
A selected working ICE pair, established DTLS and increasing packet counters are supporting media evidence, not proof of an agent/customer bridge.
If this check fails
No candidate or failed DTLS: inspect certificate trust, WebSocket, ICE and reachable media first; stop before guessing at conference settings.
Step 2Identify the actual bridge and both legs
During a separately approved synthetic test, inspect current bridge and channel IDs, then correlate the test agent and customer legs; use installed CLI help to check available bridge commands.
For example, an agent leg in bridge A and a customer leg absent from A indicate a routing or handoff branch to investigate, not a proven ICE fault.
Before you use it
Run only on an authorized isolated lab or approved read-only diagnostic session; substitute placeholders. Preserve sensitive data privately.
Identify the actual bridge and both legs
```
asterisk -rx 'core show help bridge'asterisk -rx 'bridge show all'
```
Reader-run example · not executed for this guide
This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.
Success looks like
Both intended test channels are in the intended bridge at the same time.
Stop if
If channel data or permissions are insufficient, retain the result as unknown; never infer joining from registration alone.
Expected observation
Both intended test channels are in the intended bridge at the same time.
If this check fails
If channel data or permissions are insufficient, retain the result as unknown; never infer joining from registration alone.

Correct the confirmed cause

Use this branch only when your diagnostic observations match the affected scope above. The lab result states which outcomes were actually tested.

Step 3Correct only the proven branch
Record before-state. If ICE or DTLS failed, have the authorized owner correct the documented endpoint/certificate/network mismatch; if both media paths work but bridge membership differs, investigate installed VICIdial handoff and conference configuration.
Expected observation
Correction corresponds to evidence from the failing layer.
If this check fails
Do not switch conference engines or transports as an untested shortcut.

Verify the outcome

Repeat the same bounded test, observe both bridge members and two-way audio; record ICE/DTLS and time-correlated evidence separately.

Recover or roll back

Restore the recorded configuration through the approved native workflow, verify registration and repeat the baseline test.

Screenshot evidence

No native screenshot is attached to this guide.

Configuring Asterisk for WebRTC Clients · Primary documentation; checked 2026-11-07

Actions to avoid

Do not disable TLS, certificate validation, or browser security controls to make a test pass.