I want to integrate Asterisk with Salesforce for VoIP functionality and would like to understand what components or configurations are required for this integration.
Is it possible to create a custom VoIP-related module or integration in Salesforce to connect it with Asterisk?
Also, can this be done without purchasing the Salesforce VoIP/CTI module? If anyone has experience with this setup.
please suggest the best approach to achieve this integration.
The “old simple way” (around 6 years ago) to achieve this was to use Salesforce Open CTI.
It allows you to embed a custom iframe directly inside the Salesforce UI, where you can implement whatever you need, and interact with Salesforce using the Open CTI JavaScript API (for example: screen pop or click-to-dial). A good reference point i used was the Twilio sample integration available on GitHub.
(care it is now really old)
This approach is still perfectly valid in 2026: it’s free, relatively simple, and gives you full control.
That said, Salesforce has introduced many new modules and integration patterns since 2020, some of which may be better suited depending on your use case—so it’s worth reviewing those options first.
If you do go with Open CTI, the real challenge will be building (or embedding) a WebRTC softphone inside that iframe. You’ll then need to connect this frontend to Asterisk.
A clean modern approach would be something like:
[Salesforce iframe (Open CTI softphone)]
⇅ WebSocket
[Node.js relay]
⇅ ARI / REST APIs
[Asterisk]
I’d strongly recommend using a Node.js backend as a relay between the browser and Asterisk (via ARI/REST), rather than trying to connect things directly.
NB: This is not exactly how I implemented it 6 years ago—my softphone was running outside the Salesforce iframe. I mainly used Open CTI for CRM interactions and had a simpler CTI-bridge layer instead of a full Node.js relay.
thanks @Philippe-Dechezelles
Philippe’s suggestion is solid. Here’s a more concrete breakdown of the two main paths since I’ve done this a few times.
**Path 1: AMI + Open CTI (simplest)**
This is the fastest way if you just need click-to-call and screen pops. The flow:
1. Salesforce Open CTI adapter (JavaScript in a Visualforce page or Lightning component) talks to your middleware
2. Middleware is a small Node.js or Python service that holds a persistent AMI connection to Asterisk
3. Click-to-call sends an Originate action through AMI:
```
Action: Originate
Channel: PJSIP/agent-extension
Context: from-internal
Exten: 15551234567
Priority: 1
CallerID: “Salesforce” <15559876543>
Variable: SF_CASE_ID=500ABC123
```
4. For screen pops, your middleware listens for Newchannel/Newstate events on AMI, matches the CallerID against Salesforce via the REST API, and pushes the contact record URL back to the Open CTI adapter via WebSocket
The key thing people get wrong: don’t open a new AMI connection per call. Keep 2-3 persistent connections and multiplex. Asterisk dispatches every channel event to every AMI session, so 50+ connections will choke the Stasis message bus.
**Path 2: ARI + WebRTC (more control, more work)**
If you need a softphone embedded in Salesforce (no desk phone), you’re looking at ARI + WebRTC like Philippe mentioned. The moving parts:
- ARI controls the call flow (answer, bridge, hold, transfer)
- WebRTC handles the actual media in the browser
- SRTP + WSS between the browser and Asterisk
- Salesforce Lightning Web Component wraps the softphone UI
This gives you call recording, whisper coaching, conference — everything. But it’s a real project, not a weekend hack.
**Which to pick?**
If your agents already have SIP phones: Path 1. You can have click-to-call and screen pops working in a day.
If you want a browser-only softphone inside Salesforce: Path 2, budget 2-3 weeks.
I wrote up the full AMI action reference with working code for Originate, Events, and connection pooling here: [Asterisk AMI Commands Guide]( Asterisk AMI Commands Guide | ViciStack Blog ) — covers the exact patterns you’d need for the middleware layer.
I do find it helpful to have two separate AMI connections, though: one is for sending commands and receiving responses, while the other is dedicated to receiving events. Less confusion that way.