HSG IT FinlandWebRTC Developers in Finland —
SIP, Asterisk & Browser Calling Engineers
We are a Finnish team that builds real-time voice and video into products: browser-to-browser WebRTC, SIP signalling, NAT traversal that survives mobile carriers, and Asterisk telephony. We also run our own WebRTC platform, WebCallHub — so the architecture we recommend is one we operate in production, not one we read about. Same timezone, EU-GDPR, typical start in 2 weeks.
Real-Time Voice & Video Engineering
Browser Calling (WebRTC)
Peer-to-peer voice and video straight from the browser — no app, no plugin, no phone number. Media negotiation, codec selection, echo cancellation, device switching and autoplay-policy handling on Chrome, Safari, Firefox and Edge.
SIP & Asterisk Telephony
PJSIP endpoint and dialplan design, SIP over secure WebSocket, registration and digest authentication at scale, PSTN trunk integration, and call routing that reflects how a business actually answers the phone.
NAT Traversal That Holds
The reason calls fail in the field. ICE candidate analysis, STUN/TURN deployment (coturn), TLS relay on 443 for locked-down corporate networks, and CGNAT behaviour on mobile carriers where direct media never forms.
Mobile VoIP & Push
Native call experiences that ring a locked phone: CallKit and PushKit on iOS, high-priority push and connection-service integration on Android, and background-audio behaviour that survives the OS killing your process.
Call-Quality Observability
You cannot fix audio you cannot see. RTP statistics, jitter, packet loss and MOS estimation exported to Prometheus and Grafana, plus per-call traces that tell you whether a complaint was the network, the device or your code.
Real-Time Speech Pipelines
Live transcription and voice-agent pipelines on top of a call: streaming speech-to-text, barge-in handling, latency budgeting between STT, an LLM and TTS, and graceful handoff from an automated voice to a human.
We Run Our Own WebRTC Platform
Most consultancies that list WebRTC have integrated somebody else's SDK. We build and operate WebCallHub, a click-to-call product where a website visitor presses a button and is talking to a business seconds later, in the browser, with no number dialled and nothing installed.
That product is why we know the unglamorous parts. Media is DTLS-SRTP encrypted with the browser initiating the handshake, because that is what survives NAT. Signalling is SIP over a TLS-terminated WebSocket, because HTTP-layer WebSocket proxying breaks digest authentication once you pass a handful of endpoints. Audio is Opus at up to 48 kHz. Relay is coturn, reachable on 443, because a hotel network will let nothing else through.
None of that is theory we can offer you. It is a system we are on call for.
How We Engage
WebRTC Audit
Your existing stack, examined: ICE and TURN behaviour, codec and jitter handling, signalling reliability, reconnection under network change. Deliverable is a prioritised defect list with reproductions.
Book AuditBuild the Calling Layer
Voice or video into your product end to end — signalling, media, relay, mobile push and the dashboards to run it. Scoped and priced after the audit, never before.
Scope a BuildEmbedded Engineer
A senior real-time engineer inside your team. Your sprints, your repo, our WebRTC scar tissue.
Get QuoteWebRTC FAQ
What WebRTC services does HSG IT offer in Finland?
Browser-to-browser voice and video calling, SIP-over-WebSocket signalling, Asterisk and PJSIP telephony, ICE/STUN/TURN NAT traversal, DTLS-SRTP media encryption, mobile VoIP push (CallKit/PushKit on iOS, Firebase on Android), call-quality observability, and live transcription pipelines. We work as an embedded team or on a fixed-scope build.
Have you built a WebRTC product yourselves?
Yes. We build and operate WebCallHub, a click-to-call platform where website visitors talk to a business in the browser over WebRTC — no phone number, no app, no plugin. It runs JsSIP in the browser against Asterisk PJSIP with coturn for relay, and it is in production. When we advise on an architecture, we are describing something we run ourselves.
Why do WebRTC calls fail on corporate and mobile networks?
Almost always NAT traversal. Symmetric NAT, CGNAT on mobile carriers and firewalls that permit only TCP/443 all block direct peer-to-peer media, so the call needs a correctly configured TURN relay over TLS. The second most common cause is DTLS role confusion — if the server tries to initiate the handshake instead of staying passive, media never starts even though signalling looks healthy.
Can you fix an existing WebRTC application rather than rebuild it?
Yes, and that is most of the work we are asked for. A typical engagement is a two-week audit of an existing stack: ICE candidate analysis, TURN configuration, codec and jitter-buffer behaviour, signalling reliability, and reconnection under network change. You get a prioritised defect list with reproductions rather than a rewrite proposal.
Do you work with Asterisk, FreeSWITCH or Janus?
Our deepest production experience is Asterisk with the PJSIP stack, including SIP over secure WebSocket, media negotiation and dialplan design. We also work with FreeSWITCH, Janus and LiveKit, and we will tell you plainly when a hosted CPaaS is the cheaper answer for your volume.
Is WebRTC media encrypted, and does that satisfy GDPR?
WebRTC media is always encrypted — DTLS-SRTP is mandatory in the specification, and it is the same media encryption used by Google Meet and Microsoft Teams. Encryption alone is not GDPR compliance, though: what matters for a Finnish or EU deployment is where signalling metadata, recordings and transcripts are stored and for how long. We design for EU residency and data minimisation from the start.
Calls dropping in the field?
Book a free 30-minute call. Describe the symptom — one-way audio, works on wifi but not on 4G, fine in the office and broken at a customer site — and we will tell you where in the stack to look.