VoIP.infoThe independent guide to business communications.
VoIP.info Client integration guide

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.

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 repository, documentation, package and application states separately

JsSIP is a JavaScript SIP library, not a finished phone or hosted calling service. Record the application commit, lockfile, resolved jssip package, dependency tree, bundler output and deployed asset hash. The integrating application still owns identity delivery, interface, call controls, media elements, accessibility, telemetry, updates and recovery.

The repository changelog reviewed October 23, 2026 contains a 3.13.9 heading, while the published npm latest tag remains 3.13.8 and the public versioned examples remain under 3.10.x. A main-branch heading is not proof that an npm artifact was published or deployed. Validate API and type assumptions against the exact installed package rather than silently mixing those states.

Separate the secure WebSocket from the SIP account

A WebSocketInterface supplies the SIP-over-WebSocket transport. The UA separately owns SIP URI, authorization user, password or HA1 and realm, registrar behavior, registration expiry and optional route behavior. Preserve the selected WSS URL, TLS result, origin policy, socket attempt, connected event and disconnect code before interpreting SIP state.

A connected socket proves only transport establishment. It does not prove registration, current inbound routing or a call. Protect credentials from source, client logs and analytics, prefer bounded delivery and revocation, and keep WSS hop protection separate from protection beyond the WebSocket server.

Treat registration events as their own lifecycle

The UA API distinguishes registered, unregistered, registrationFailed and registrationExpiring. Retain the response, cause, attempt sequence, expiry and refresh result. If an application subscribes to registrationExpiring, the documentation makes that application responsible for calling ua.register() before expiry; adding a listener can therefore change behavior.

Keep ua.isConnected() and ua.isRegistered() separate. A registration 2xx identifies an accepted binding at that moment, not current page execution, a retained proxy route, INVITE delivery, ringtone playback or usable media.

Preserve the RTCSession event sequence and SIP evidence

The UA newRTCSession event supplies originator, session and incoming or outgoing INVITE request. On the session, preserve progress, accepted, confirmed, failed and ended events with SIP response, cause and timestamps. Application state, SIP dialog state and what the remote party experienced are separate observations.

Use the exact failure or end cause only as a classification pointer. Connection Error, Request Timeout, SIP Failure Code, No Answer, No ACK, Dialog Error, User Denied Media Access, Bad Media Description and RTP Timeout refer to different stages; they are not interchangeable explanations.

Trace permission, SDP, ICE, tracks and playback after signaling

A confirmed session does not prove that getUserMedia() succeeded, the intended microphone was selected, SDP was acceptable, ICE chose a working pair, RTP flowed, a remote track was attached or an audio element played. Record getusermediafailed with its DOMException, local and remote SDP events, ICE candidate and connection state, peer-connection receivers, media-element attachment and the play() promise separately.

Correct the earliest demonstrated boundary. Changing SIP credentials cannot repair denied capture, and changing codecs cannot repair an unattached or autoplay-blocked remote element. Redact credentials, calling identities, ICE passwords and unnecessary SDP from shared evidence.

Retest the supported application lifecycle without inventing background reachability

Define whether the product supports only an active foreground page, an installed web application or some separately engineered notification path. A browser tab can be hidden, suspended, discarded or closed while an older registration remains visible upstream. JsSIP events observe the running application; they do not create universal push wake-up or locked-screen ringing.

After one reversible correction, repeat socket connect, registration and refresh, inbound and outbound setup, permission denial and recovery, two-way media, cancel, answer, hangup, network change and the supported background or fallback state. This is a documentation-derived acceptance plan. No package, application, browser, PBX, socket, registration, 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

Troubleshooting · 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 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.

Read guide →
Hub · Primary softphone documentation reviewed through October 10, 2026; app, package, browser, mobile-wrapper, Windows audio and PBX interoperability not lab tested

Softphone research

Choose a desktop, mobile or browser calling client by SIP account, provisioning control, encryption and reliable call delivery.

Explore topic →
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 →
Developer research · SIP.js 0.21.2 release archive, 0.20-to-0.21 migration guide, repository API scope, Simple User and mobile guides, and the repository's published security-policy table were reviewed October 8, 2026; the release archive labels 0.21.2 Latest while the security table names 0.19.x as supported, and no package, dependency tree, application build, browser, mobile wrapper, permission, SIP account, WSS endpoint, PBX, media path, background delivery, compatibility or call was inspected or tested

SIP.js browser calling: package, media and lifecycle boundaries

Choose the documented SIP.js layer, pin its release and prove signaling, media and browser recovery separately.

Read guide →
Guide · RFC 7118 and Asterisk documentation reviewed October 5, 2026; no browser, proxy, PBX or call laboratory validation

SIP over WebSocket and WSS

Separate the browser signaling transport from the media transport when connecting a web softphone.

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 →
Protocol reference

SIP REGISTER explained

Understand contact bindings, authentication challenges and why registration does not prove calling works.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

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 →