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

JsSIP connects or registers but calls or audio fail

Trace one JsSIP failure from exact package and page lifecycle through WSS, REGISTER, INVITE, RTCSession, permission, SDP, ICE, RTP and media playback.

Reviewed 2026-10-23Current JsSIP project, documentation, UA and RTCSession APIs, cause catalogue, repository, changelog and published npm package reviewed October 23, 2026; the repository changelog contains a 3.13.9 heading while the npm latest tag remains 3.13.8 and the public versioned examples remain under 3.10.x, so repository, documentation and installed-package state are not treated as interchangeable; exact application, package lock, bundle, browser, origin, credential delivery, SIP service, PBX policy, WebSocket, registration, page lifecycle, permission, device, SDP, ICE, RTP and playback remain deployment specific; no package, dependency tree, application, browser, account, credential, socket, registration, SIP message, permission, device, media element, peer connection, packet, media stream or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze one application build, browser state and failed attempt

Record timestamp and timezone, application commit, resolved JsSIP version, lockfile and bundle hash, browser and operating-system versions, page origin and visibility, WSS URL, protected SIP identity, registration state, call direction, target, Call-ID and the first missing event. Redact credentials and unnecessary calling data.

Classify the earliest divergence: package or API mismatch; WSS never connects or drops; registration fails or expires; INVITE never creates the expected RTCSession; session fails before confirmation; capture fails; SDP or ICE fails; RTP is absent; remote tracks are not attached; playback is blocked; or the page is suspended or gone.

Prove package and API ownership before changing the network

Compare the deployed bundle with the resolved package rather than a repository branch. The changelog currently contains a 3.13.9 heading, npm latest remains 3.13.8 and the versioned public examples remain under 3.10.x. Confirm that event names, types and integration code match the installed artifact.

Reproduce under the same built application. A successful repository example, demo or development branch does not prove the production bundle imported the same code or API.

Follow WSS and registration as two transactions

Preserve connecting, connected or disconnected with socket, attempt count, close code and reason. Then capture REGISTER, challenge, authenticated retry, final response, expiry and refresh. Keep TLS validation, WebSocket origin policy, SIP authentication and registrar authorization separate.

If the application listens for registrationExpiring, verify that it calls ua.register() in time. A connected socket with no registered binding and a registered binding on a page that later stopped are different faults.

Trace INVITE and RTCSession events before media

For an inbound attempt, prove that newRTCSession fired with remote originator and the expected incoming INVITE. For an outbound attempt, preserve the target and outgoing request. Follow progress, accepted, confirmed, failed and ended events with response, cause and timestamps.

Do not flatten Request Timeout, SIP Failure Code, No Answer, No ACK or Dialog Error into a generic media problem. Correct the demonstrated SIP, routing or application-state boundary before inspecting codecs.

Localize capture, SDP, ICE, RTP and playback independently

Record microphone permission and any getusermediafailed DOMException. Preserve sanitized offer and answer direction, ICE gathering and selected candidate pair, peer-connection state, RTP counters, receiver tracks, constructed MediaStream, audio-element attachment and the play() result.

A confirmed RTCSession is signaling evidence. It does not prove capture, selected devices, a working ICE pair, packet flow, decoded audio or an audible element. Use the dedicated microphone and audio-device diagnostics when those are the first failed boundaries.

Correct one boundary and repeat the intended lifecycle

Apply one reversible correction, then repeat the same build, identity, route and call. Verify socket connection, registration refresh, inbound and outbound session creation, answer, two-way audio, cancel and hangup. Re-test the exact network-change and page-visibility state that exposed the fault.

Define a fallback for closed or suspended pages rather than representing an old registrar contact as background availability. Remove temporary debug logging and retain only redacted event timing and outcome. No package, application, browser, account, socket, registration, SIP message, permission, device, peer connection, packet, media stream or call was inspected or tested.

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

Client integration guide · Current JsSIP project, documentation, UA and RTCSession APIs, cause catalogue, repository, changelog and published npm package reviewed October 23, 2026; the repository changelog contains a 3.13.9 heading while the npm latest tag remains 3.13.8 and the public versioned examples remain under 3.10.x, so repository, documentation and installed-package state are not treated as interchangeable; exact application, package lock, bundle, browser, origin, credential delivery, SIP service, PBX policy, WebSocket, registration, page lifecycle, permission, device, SDP, ICE, RTP and playback remain deployment specific; no package, dependency tree, application, browser, account, credential, socket, registration, SIP message, permission, device, media element, peer connection, packet, media stream or call was inspected or tested

JsSIP browser calling: package, transport, registration and media evidence

Operate a JsSIP integration without confusing repository, published package, WebSocket state, registration, RTCSession, browser permission, peer connection or audible media.

Read guide →
Guide · Current SIP.js release, migration, repository, Simple User, mobile and security-policy documentation plus MDN, W3C and Asterisk references reviewed October 8, 2026; no package, application, browser, mobile wrapper, PBX, permission, notification path, media path or call was inspected or laboratory-tested

Browser webphones: microphone permission and audible-call checks

Trace browser calling through secure origin, capture policy, device selection, SIP session, remote media and playback before changing the network.

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

WebRTC troubleshooting by connection stage

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

Read guide →
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 · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

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 →
Troubleshooting · Current Microsoft Windows microphone permission and troubleshooting guidance, Apple macOS and iPhone microphone controls, Android permissions, RFC 3264 offer/answer, RFC 3550 RTP and Asterisk PJSIP troubleshooting documentation reviewed October 6, 2026; no workstation, mobile device, microphone, headset, softphone, operating-system policy, SIP account, PBX, packet capture, protected-media path or call was inspected or tested

Softphone microphone is silent: prove capture before RTP

Separate operating-system permission, selected input, client mute and capture, SDP direction, outbound RTP and remote decode when callers cannot hear a softphone user.

Read guide →
Troubleshooting · Current Microsoft Windows audio-device and per-app routing guidance, Apple macOS input and output guidance and AVAudioSession route-change documentation, Android AudioManager reference, and W3C Media Capture and Audio Output specifications reviewed October 6, 2026; no computer, mobile device, dock, USB interface, Bluetooth device, browser, softphone, operating-system policy, PBX, media path or live call was inspected or tested

Softphone uses the wrong speaker, headset or microphone

Separate the connected device, operating-system defaults, per-app route, softphone selection, browser permission and active call path after docking, Bluetooth or USB changes.

Read guide →