Asterisk WebRTC registers but the call has no audio

Do not treat registration as a media test

Preserve one affected call's time, SIP Call-ID, browser and operating-system version, endpoint name and intended peer. Confirm separately that HTTPS loaded, WSS selected the SIP subprotocol, SIP authentication completed, a Contact was stored, the INVITE was answered and the final ACK was sent. Those signaling states do not establish a working WebRTC media path.

Then state the symptom precisely: neither side hears audio, only one direction is missing, remote audio bytes arrive but nothing plays, or media stops after hold or another offer. Check browser microphone permission, chosen input and output, mute state and remote-media attachment before changing the PBX.

Read the final SDP on both Asterisk call legs

For the browser-facing leg, preserve the final offer and answer, including each audio m-line, direction, accepted codec and payload mapping, ICE username fragment, candidate set, fingerprint, setup role, RTCP multiplexing and media profile. Asterisk's WebRTC configuration uses AVPF, ICE, DTLS media encryption and RTCP multiplexing; its res_pjsip reference says webrtc=yes defaults the related endpoint options. Record the loaded endpoint rather than assuming a template or generated file became effective.

Keep the browser-facing WebRTC leg separate from the other Asterisk channel. A SIP trunk or conventional phone can use a different codec, address, port and media-security profile. Evidence that packets reached the trunk leg does not prove Asterisk emitted valid SRTP toward the browser, and browser candidates are not settings to paste into the carrier trunk.

Find the selected ICE pair before debugging SRTP

RFC 8445 defines the selected pair as the nominated local and remote candidates used for a media component. In browser diagnostics, preserve ICE state, selected candidate-pair identifier, local and remote candidate types and addresses, nomination state, sent and received packet or byte counters, responses received and timestamps where exposed. A candidate merely present in SDP is not proof that its connectivity check succeeded.

If no pair is selected, compare candidate gathering and checks on the browser with Asterisk's ICE evidence. Determine whether host, server-reflexive or relay candidates were actually available and whether the expected UDP path or TURN relay was reachable. Test a relay policy as a bounded experiment when authorized; do not publish a permanent open firewall range or assume that configuring a STUN or TURN URL proves the service was used.

Prove that DTLS established the SRTP context

RFC 5764 uses the DTLS handshake on the media path to establish SRTP keying material. RFC 8842 connects the SDP fingerprint and setup role to that association. After ICE selects a path, preserve the browser's DTLS state and any fingerprint or handshake error, then correlate it with Asterisk's time-bounded log for the same channel. Selected ICE connectivity without a completed DTLS association can still produce an answered, silent call.

Compare the fingerprint and setup attributes from the final negotiated SDP, not a draft offer. Check the effective Asterisk endpoint certificate and DTLS options. Do not disable fingerprint verification or replace DTLS-SRTP with clear RTP as the production repair; identify certificate, role, profile, version or packet-path evidence first.

Trace protected media and playback as separate outcomes

Once ICE and DTLS are established, compare browser outbound and inbound RTP or audio counters with Asterisk's browser-facing channel and the other call leg. Preserve candidate-pair bytes separately from inbound-rtp audio bytes because connectivity checks and control traffic do not prove audio payload arrived. With SRTP, packet presence and timing do not prove that decryption, decoding or audible playback succeeded.

If browser inbound audio counters rise but the user hears silence, return to output selection, remote track attachment, autoplay or application state. If Asterisk receives browser media but the far leg does not, follow translation, bridge and the far leg. If the PBX sends browser-facing packets but browser inbound media remains flat, follow the selected tuple across the intervening path.

Correct one demonstrated boundary and retest

Correct only the boundary supported by evidence: browser permission or device selection, final SDP policy, candidate gathering, TURN authorization, firewall or NAT path, loaded PJSIP WebRTC endpoint, DTLS certificate or role, codec translation, bridge behavior or application playback. On FreePBX, make endpoint and network changes through the supported GUI or configuration ownership path rather than overwriting generated files.

Repeat incoming and outgoing calls with both directions, then hold and resume, transfer and an idle-period call where relevant. Preserve signaling, selected ICE pair, DTLS state, media counters and user-confirmed audio as distinct results. No browser, Asterisk system, FreePBX system, media path, compatibility, availability or call was tested for this guide.

Branch to the application-media diagnostic only when chan_websocket is present

If the silent leg is an application WebSocket/... channel rather than the browser's ICE and DTLS-SRTP path, use the chan_websocket diagnostic. A browser registration, ARI connection and media WebSocket are separate evidence.