From “What is a SIP Trunk?” to Banking- Grade WebRTC: My Engineering Journey

When I first joined my current company-an Avaya partner- I felt like I had stepped into a different dimension. My background was in standard software development experience, but suddenly, I was drowning in a sea of three-letter accronyms. People were talking about SIP, Trunks, SDP, RTP, and “Avaya thingies” that sounded like they belonged in a sci-fi movie.

If you’ve ever felt overwhelmed by the jump from standard web dev to enterprise telephony, this story is for you.

Learning The “Telecom” Dictionary

in my first weeks, I had to learn the language of voice:

• SIP (Session Initiation Protocol): Think of this as the “handshake”. It’s the language phones use to invite each other to a call.
• SIP Trunk : the virtual version of those old physical phone lines. It’s how your PABX(the “office phone brain”) talks to outside world.
• SDP (Session Description Protocol) : If SIP is the invitation, SDP is the details. it tells the other side: “I want to talk, here are my audio/video formats (codecs) and port where you should send the data.”
• RTP (Real-time Transport Protocol): Once the handshake is done, this is the “truck” that actually carries your voice and video packets accross the internet.

Stepping into WebRTC

I eventually realized that WebRTC was the missing link between our Avaya infrastructure and the modern mobile apps our customers were building.

Unlike traditional VoIP, which often relies on a central server to mediate every single conversation, WebRTC allows browsers and apps to talk directly each other (Peer-to-Peer). However, in an enterprise bank setting, we can’t just have random browsers talking to each other. We need control, security, and integration with our existing Avaya PABX.

Our Architecture for the Bank

Our challenge was to enable VoIP calling directly inside a secure mobile application for a major banking client. We weren’t building a consumer app; we were extending the bank’s exterprise Avaya infrastructure.

We designed a robutst pipeline where WebRTC was the secure entry point.

To make a mobile app “talk” to an Avaya system, we built a robust pipeline:

1. Mobile App: Users tap “Call” in their banking app
2. Token Auth Service : Before the call starts, the app requests a temporary, time-bound token from our service. This ensures only authorized users can initiate a connection. So the Mobile apps do not talk directly to the Avaya Aura Web Gateway (AAWG). Instead, we built a custom Token Auth Service. The mobile app sends a request to this service with a secret key. Only then does our service authenticate the request and call the AAWG to generate an encrypted token.
3. AAWG (Avaya Aura Web Gateway): This is the magic component. The mobile app passes this token to the Avaya Aura Gateway to initiate the call. AAWG takes the WebRTC signal from the mobile app and translates it into a language the PABX understands. In the Avaya ecosystem, this is a purpose-built component that handles the complexity of signaling and media so your application doesn’t have to.
4. SBC (Session Border Controller: The “Bouncer”. It sits at the edge of the network, hiding our internal IP address (topology hiding), scrubbing bad traffic, and acting as the gateway for media. In a WebRTC deployment, the SBC performs transcoding and provides the essential security layer, terminating TLS/DTLS handshake before traffic hits your internal networks
5. CRM Pop-Up Integration: When a VoIP call hits the banking internal CRM, the Avaya system identifies the caller and triggers a browser/app event. This automatically launches a CRM pop-up for the agent, pre-loading the customer’s data based on the caller ID. It transforms a standard phone call into a context-aware service interaction.

Engineering Challenges :

• The Android 16 Supported

We were blocked for a long time trying to certify the app for Android 16. The official Avaya documentation only listed support up to Android 15, and when we tested our React Native (v0.77) build on the emulator, it crashed consistently. We were stuck in a loop of troubleshooting , trying to upgrade react version, testing it, until our client tested it on a real Android 16 device. It worked perfectly. sometimes the environment is the problem, not your code.

• The Bluetooth-to-Speaker Audio Bug

We also faced a nasty bug where switching audio output from the Bluetooth to the phone’s speaker caused the voice to dissapear entirely. We had to dig deep into the audio session management and how the WebRTC SDK handles device switching. After some insense debugging of our audio manage layer, we were able to force the session to reinitialize correctly during the output transition, restoring seamless audio.

There are still several challenges occured that finally we managed to solve them.

Addressing the Pentest

The pentesters found links from certain endpoint payload and flagged them as a “sensitive data exposure” and initially requested that we remove or update this vendor-supplied link. Our first instinct was to clarify that those links structure is an immutable part of the underlying Avaya Aura Web Gateway (AAWG) framework — it is not a custom endpoint we built or control. However, simply saying “it’s a vendor issue” rarely enough for a thorough security audit. Instead, I shifted the conversation to risk validation and architectural behaviour. I explained that while the URL structure exists within the payload, it does not represent an exposed vulnerability because of how we manage the session:

• Separation of Concerns: the mobile app does not interact with that specific resource link to manage the call. The link is part of the standard AAWG discovery process, which the Avaya WebRTC SDK handles internally as part of its initialization logic.
• Tightened Security Perimater: We mitigate the risk by strictly controlling the Token Auth Service that wraps these interations. Because the token is valid for only 20 seconds (This is very tight “validity window”) even If a third party intercepts an encrypted token and tries to use it to call an API (like terminateCall) on the 21st second, the Avaya server will immediately reject the request with a 401 Unauthorized error
• Stateful Security (WebSocket vs REST API)

this was the most important distintion to make:

• The SDK is Stateful: the mobile app doesn’t manually “call” those REST API links after the initial handshake.
• The Handshake: the token is used exactly one at the beginning to establish a secure, persistent WebSocket connection via the Avaya WebRTC SDK.
• Internal Signaling: Once the call is live, operations like terminateCall are handled internally by the SDK. the command is sent as an encrypted signal inside the existing, authenticated WebSocket pipe.

Because the API endpoints are never exposed to manual HTTP calls after that 20-second window the “links” in the payload are essentially useless to an attacker. We weren’t just providing a service; we were building a secure, stateful communication tunnel.

Closing Thoughts

Whether you are working with an Avaya Aura Environment, a Cisco Unified Communication setup, or an Asterisk-based PBX, the fundamental challenge remains the same: Translating modern, web-native signals into the reliability of enterprise-grade telephony.

We aren’t just “providing VoIP”. We are building bridges between a bank’s digital mobile experience and the highly secure, proven infrastructure of the corporate telephony world.