VoIP.infoThe independent guide to business communications.
VoIP.info Guide

WebRTC troubleshooting by connection stage

Locate failures in capture, signaling, ICE, DTLS or playback using an ordered evidence trail.

Reviewed 2026-10-09WebRTC standards; browser and server behavior must be checked by versionIntermediateDocumentation based · not lab tested

Find the first failed stage

Start with a single affected call and a timestamp. Check microphone capture, application signaling, session negotiation, ICE connectivity, DTLS keying and media flow in that order. Some stages overlap, but this sequence prevents a media problem from triggering unrelated credential changes. Record the exact browser, operating system and client release. A reproducible result on one network and failure on another is more useful than a general statement that browser calling is unreliable.

Find the first failed connection stage
Working signaling provides session descriptions. ICE checks select a candidate pair, then DTLS establishes media keys. Incoming and outgoing media statistics and local capture or playback determine whether sound reaches the user.

A diagnostic order, not a strict application timeline: capture can start earlier and ICE gathering may be incremental. Successful signaling alone does not prove audio works.

Read counters with state

Inspect connection-state changes, the selected candidate pair, codec and inbound/outbound RTP statistics. Increasing bytes on a candidate pair may include control traffic; inspect media-specific counters too. Received RTP with no audible output points toward a different investigation from no incoming packets. Compare both endpoints or the browser and PBX. A server-side media count does not establish that the browser decoded and played the audio. If the call goes through a media relay or B2BUA, keep each leg's evidence separate and correlate it by the application's call identifier.

Use one controlled change

Repeat with a known audio device, then a different network, then a deliberate relay test as separate experiments. Changing all three at once may recover the call while leaving the cause unknown. Preserve diagnostics before reloading the page or clearing application state. After a fix, test incoming calls following an idle period, hold/resume, network change and device replacement. Keep a concise incident record: failing stage, evidence, bounded change and observed recovery. Do not include passwords, authorization headers or unnecessary audio recordings in a routine support export.

Apply the connection stages to Asterisk

For an Asterisk browser endpoint, the registration-without-audio diagnostic records the loaded PJSIP WebRTC options, final SDP on both call legs, nominated candidate pair, DTLS state and direction-specific media counters.

Split incoming-call alerting from post-answer media

The browser no-ring diagnostic keeps INVITE delivery, ringtone element, user activation, AudioContext state and the later remote WebRTC track separate. A silent ringtone is not evidence of failed ICE or RTP.

Watch the explanation

What are the reasons for WebRTC to discard audio packets?Tsahi Levent-Levi · 1:57 · Conceptual

Explains why an audio packet can arrive yet be discarded before playback. This distinction helps separate network loss from jitter-buffer and timing problems.

Read applicability and editorial notes →
Watch this video here

Conceptual browser-media discussion from 2024. Specific receiver algorithms and statistics vary. Review used the available transcript and primary references; audio and screen readability remain unverified.

Open on YouTube ↗

The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.

ICE candidates and the active WebRTC connection in webrtc-internalsTsahi Levent-Levi · 7:23 · Version-specific

Follows candidate pairs in a live browser session, then finds the same selected pair in an exported diagnostic dump. This connects ICE terminology to an actual troubleshooting workflow.

Read applicability and editorial notes →
Watch this video here

A March 2025 Chromium walkthrough with Philipp Hancke; browser diagnostic layouts can change. Review used the available transcript and primary references; audio and screen readability remain unverified.

Open on YouTube ↗

The player loads only when you choose Watch here. Playback uses YouTube’s privacy-enhanced embed; YouTube processes playback data.

Explore all 3 related videos →

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · WebRTC standards; browser and server behavior must be checked by version

Browser microphone and audio-device troubleshooting

Isolate permissions, capture, transport and playback before changing the PBX.

Read guide →
Guide · WebRTC standards; browser and server behavior must be checked by version

ICE: candidate gathering, checks and the selected path

Understand how WebRTC finds a usable media route and what an ICE failure actually narrows down.

Read guide →
Guide · WebRTC standards; browser and server behavior must be checked by version

DTLS-SRTP: separate signaling trust from media keys

Follow the media handshake and identify where encrypted browser audio terminates.

Read guide →
Diagnostic · Current Asterisk WebRTC and res_pjsip documentation, RFC 8445, RFC 5764, RFC 8842 and the W3C WebRTC Statistics API were reviewed October 7, 2026; no Asterisk or FreePBX host, browser, endpoint, certificate, ICE server, TURN relay, firewall, NAT, media path, packet, call, compatibility or availability was inspected or tested

Asterisk WebRTC registers but the call has no audio

Separate WSS and SIP success from SDP, ICE, DTLS-SRTP, packet flow and browser playback before changing PJSIP or firewall policy.

Read guide →
Troubleshooting · Current first-party SIP.js call-receive, user-agent, media and mobile guidance plus MDN, Chrome and WebKit playback, AudioContext and visibility documentation reviewed October 9, 2026; browser autoplay behavior is policy- and state-sensitive, the SIP.js mobile statement is limited to compatible foreground web applications, and no package, application, origin, browser, tab, operating system, user gesture, media element, audio context, WebSocket, registration, INVITE, device, PBX, ringtone, notification, media path or call was inspected or tested

Browser softphone receives the INVITE but does not ring

Separate WSS and registration, INVITE delivery, visible call state, ringtone playback policy, user activation, answer and remote media before changing SIP routing.

Read guide →