Outbound Calling From Your CRM: How SIP Trunk Integration Works

The Four Layers Between a CRM Click and a Connected Call

When a sales agent clicks a phone number in their CRM and a call connects to the prospect's phone, four things happen in sequence:

Layer 1 — Signaling initiation. The CRM (or its browser-based softphone plugin) sends a SIP INVITE to the configured SIP gateway. This INVITE contains the destination number, the caller ID to present, and the agent's SIP credentials.

Layer 2 — Authentication and routing. The SIP gateway authenticates the credentials, validates the caller ID against the account's provisioned numbers, and routes the call to the appropriate PSTN termination path for the destination country.

Layer 3 — PSTN termination. The call traverses the carrier network to the destination number. For US and Canadian calls, STIR/SHAKEN attestation is applied in this layer. The receiving carrier presents the call with the caller ID and any trust signals.

Layer 4 — Event postback. When the call completes, the SIP gateway posts a call event (duration, answer status, hangup cause) to a webhook endpoint configured on the account. The CRM picks up this event and writes the call record to the contact timeline.

Each layer must be configured correctly for end-to-end functionality. Most CRM-to-SIP integration problems originate in layers 1 (credential misconfiguration) or 4 (missing or misconfigured webhook).

What Your CRM Needs to Support SIP Outbound

Not every CRM has a native SIP client. The options depend on your CRM's architecture:

Native WebRTC softphone. Some CRMs (GoHighLevel, HubSpot calling, Salesforce's embedded dialer) include a built-in WebRTC softphone that connects to a SIP gateway directly. You supply credentials; the CRM handles the browser-to-SIP signaling. No separate client needed.

CTI integration layer. Enterprise CRMs often use a CTI (computer-telephony integration) adapter — a middleware layer that translates CRM click events into SIP calls. Salesforce CTI adapters, for example, sit between the CRM interface and the SIP provider.

Third-party softphone with CRM plugin. Tools like Zoiper, Bria, or Linphone can be connected to a SIP trunk and extended with CRM plugins that log calls automatically. This works with any CRM that has an API but no native calling layer.

For teams on GoHighLevel, the native WebRTC softphone plus BYOC is the cleanest path — see the GoHighLevel SIP trunk connection guide for step-by-step configuration.

Caller ID Assignment per CRM User

Most SIP trunks assign one caller ID to an account. For a CRM deployment where different agents need to present different numbers — territory-specific local presence, for example — you need per-seat caller ID assignment.

UnlimCall provisions caller IDs on demand across 33 live markets. Each seat gets a dedicated DID. In a CRM context, this means each agent's SIP credential set is paired with a specific DID, and that DID is presented as the caller ID on every outbound call from that seat.

The provisioning flow: request the DID for the target country in the portal, receive the number, assign it to the relevant seat credential, and configure the CRM user's calling profile to use that credential set. The number is provisioned to your account — not drawn from a shared pool.

Handling Call Outcomes: Webhook vs. API Pull

CRM call logging happens in one of two ways: the SIP provider pushes call completion events to a webhook, or the CRM polls the provider's API for recent call records.

Webhook push is strongly preferred. The latency between call completion and CRM record update is sub-second rather than polling-interval-dependent. Agents can see the call in the timeline before they have finished writing their disposition notes.

To configure webhook postback with UnlimCall, set the webhook endpoint URL in the portal to your CRM's inbound webhook receiver. The event payload includes call UUID, from number, to number, answer time, duration in seconds, and hangup cause code. Most CRM workflow engines can parse this payload directly without transformation.

For CRMs that require a specific payload format or field mapping, a lightweight Cloudflare Worker sitting between UnlimCall's webhook and the CRM endpoint handles the transformation at the edge with no additional server infrastructure. The custom SIP integration guide documents the payload schema.

Audio Quality Considerations for WebRTC-to-SIP Paths

Browser-based WebRTC softphones introduce a codec negotiation step that does not exist in hardware phone-to-SIP paths. The CRM's WebRTC layer typically negotiates Opus for the browser-to-gateway leg, and the gateway transcodes to G.711 (PCMA or PCMU) for the PSTN-facing leg.

The transcoding step adds a small amount of latency (typically 20–40 ms) and can introduce audio artifacts if the transcoder is misconfigured or overloaded. Signs of a transcoding problem: one-way audio, clipping at the start of speech, or echo on the agent side.

For outbound-heavy teams where call quality is a direct revenue factor, testing audio quality with a real prospect number (not an internal test extension) before rolling out to agents is necessary. One-way audio issues that do not appear in internal tests are a classic symptom of NAT traversal misconfiguration between the browser client and the SIP gateway.