VoIP Hacks & Workarounds That Became Standards, and Acrobits’ Pioneering Role

From hacks to standards in VoIP

The VoIP world has always been shaped by ingenuity. When something didn’t work, developers and engineers hacked their way around it, and often those hacks hardened into industry standards. Here are some of the most influential:

NAT Traversal → STUN, TURN, ICE

Early VoIP calls often failed when devices sat behind NAT or firewalls. The first workaround was to “ask a server” (STUN) what the device’s public IP looked like. That hack grew into TURN (relay servers) and eventually ICE, which is now the standardized connectivity method used by both SIP and WebRTC.

SIP keep-alives → SIP outbound (RFC 5626)

To stay reachable behind NAT, SIP clients used to send improvised REGISTER refreshes or TCP keep-alives. Over time, this became formalized in SIP Outbound, which standardizes multiple persistent flows and keep-alive mechanisms - turning messy hacks into predictable behavior.

AJAX-style workarounds → SIP over webSockets

Browsers don’t support raw SIP over UDP/TCP. The workaround was to tunnel SIP messages through WebSockets. This hack gained traction, and today SIP over WebSockets is the recognized way to bring SIP into WebRTC-based web applications.

Pre-Shared Keys → DTLS-SRTP

In the early days, encrypting media with SRTP often required clumsy pre-shared keys or proprietary key exchanges. The workaround was to reuse TLS handshakes over datagrams - DTLS-SRTP. It became not only a standard but a mandatory media security model for WebRTC.

Codec fragmentation → Opus

Narrowband codecs (G.711, GSM, SILK) worked in some environments, wideband (CELT, AMR-WB) in others. Developers hacked around by switching codecs on the fly. The solution was to merge the best of SILK (speech) and CELT (music) into Opus - now the universal audio codec of WebRTC. Supported in softphones by Acrobits from the very beginning.

Ad hoc edge devices → Session Border Controllers (SBCs)

At first, SBCs were deployed as “patch boxes” to normalize SIP signaling, fix NAT issues, and enforce security policies. The industry soon realized that they solved too many problems to be optional. Today, SBCs are not a hack but a core architectural element in any serious VoIP network.

Background SIP on mobile → Push Notifications

When Apple killed background SIP, Acrobits built push servers to bridge SIP INVITEs into Apple Push Notifications. That workaround eventually became formalized with PushKit/CallKit, and is now the only way to deliver VoIP calls on iOS.

Also read: How to test and launch a VoIP softphone app

The push notification story

Push for VoIP is one of the clearest examples of a hack that became a standard. What started as a survival tactic turned into the only accepted way to deliver mobile VoIP.

The problem: iOS kills background SIP

In 2010, iOS 4 changed how background processes worked. Apps could no longer run SIP stacks in the background to listen for INVITE requests. That meant if your softphone wasn’t in the foreground, you simply missed calls. For many providers, it looked like iOS VoIP was dead.

The workaround: Build a push bridge

To get around this, early innovators, including Acrobits, designed a push server model. Instead of the app itself staying awake, the SIP server sent call requests to a middle service. That service converted the incoming INVITE into an Apple Push Notification, which woke the app. The app then quickly re-registered to SIP and established the call.

Acrobits’ pioneering role

Acrobits was one of the first to roll out a production-ready push infrastructure. Because their Cloud Softphone platform was white-label, carriers, ITSPs, and PBX providers around the world could adopt the workaround without building push systems themselves. This helped normalize the architecture long before Apple offered official support.

Apple formalizes the model: PushKit and CallKit

In 2015-2016, Apple introduced PushKit (for VoIP push) and CallKit (for integrating calls with the iOS dialer UI). These frameworks effectively mandated the push approach as the only compliant way to handle incoming calls. For Acrobits’ customers, the transition was smooth - they were already running on a mature push system.

The Result: from workaround to requirement

What started as a hack to keep VoIP alive on iOS has become a mandatory design choice. Today, no VoIP app can work on iOS without push, and even Android has moved in the same direction with power management features like Doze and Firebase Cloud Messaging.

Why does this matter?

The evolution of push notifications for VoIP shows a familiar pattern in telecom innovation:

Step 1: The hack

Developers invent quick fixes to keep systems alive when platforms or networks impose new limits.

Step 2: The survival phase

Those fixes spread fast because they are the only way to keep services working.

Step 3: The standard

Eventually, the workaround is recognized, formalized, and baked into platform requirements or RFCs.

Push for VoIP followed this exact arc

It started as a hack to bypass iOS background restrictions, became the survival mechanism that kept iOS VoIP alive, and then turned into the only approved method for call delivery on mobile.

Acrobits’ role in this story was critical - by pioneering a production-ready push infrastructure early, we enabled carriers, ITSPs, and PBX admins worldwide to keep their VoIP services viable on iOS without reinventing the wheel. That groundwork shaped how the entire industry delivers mobile VoIP today.

At Acrobits, we perceive hacks not as ugly shortcuts but as the first step toward progress. The key is adopting them early, refining them, and being ready when they evolve into tomorrow’s standards.