Feature · CRM Telephony Integration

The protocol layer under every connected call.

Telephony integration is the technical substrate. SIP signalling, WebRTC media, CTI event emission, screen-pop RPC, carrier metadata correlation, STIR SHAKEN attestation. The dialer surface and the vendor adapters all sit on top. This page is for engineers and telephony admins who want to read the contract.

Start free trial See pricing
The stack

Five layers under every connected call.

Strkr telephony is a layered stack. Each layer solves a single problem and exposes a well-defined contract upward. The architecture lets a vendor adapter author plug into the right layer without re-implementing the dialer, the record correlation, or the audit logging.

Layer one

Carrier network and SIP signalling.

The outermost layer is the carrier network: PSTN origination and termination for Strkr Messaging, SIP trunks for self-hosted PBX scenarios, vendor-managed signalling for RingCentral and Dialpad. SIP INVITE, 180 Ringing, 200 OK, ACK, BYE establish and tear down call legs. Strkr treats this layer as read-only; signalling control stays with the vendor side.

Layer two

Media path: WebRTC or vendor softphone.

The audio path is designed to run over WebRTC for the Strkr native dialer (browser-based, no plugin) when voice ships on the Strkr Messaging roadmap in 2027-Q1. Until then, the audio path stays inside the connected vendor softphone through standard adapters. WebRTC uses SRTP for media encryption with modern audio codecs at 48 kHz on the native path and G.722 or G.711 on carrier handoff.

Layer three

CTI event emission.

The CTI layer emits five canonical event types regardless of underlying vendor: Ring, Answer, Dial, Hold, Hangup. Each event carries a session UUID, timestamps at millisecond precision from the carrier side, directional flag, caller ID, DNIS, and the rep user identity. The event stream is append-only and tamper-evident per audit log requirements.

Layer four

Record correlation.

The correlation layer matches caller ID and DNIS against the Strkr contact database using exact-phone lookup. On match, the session UUID binds to the record. On no-match, the session carries a null record pointer and the rep can bind the session after the call during a stub-create flow. Correlation runs inside 200 ms of the Ring event firing.

Layer five

Screen pop RPC.

The screen pop layer broadcasts a record-pop event over the rep session channel (persistent websocket). The client renders the context card inside 400 ms of the Ring event on healthy regional backbones. The pop is idempotent: a reconnect after a network blip re-pops the current call without a duplicate card. The RPC contract is published in the open API.

Layer six

Record write.

The final layer writes the call session row to the database on Hangup, with all collected metadata, the disposition if the rep picked one, and the recording reference. The write is transactional with the activity timeline update. On write failure (rare, usually a transient Postgres connection), the queue retries with exponential backoff.

STIR SHAKEN and compliance

Signed attestations and modern caller ID.

FCC rules require carrier-level STIR SHAKEN attestation on US origination; UK and EU regulators are converging on similar frameworks. Strkr Messaging signs with A-level attestation on tenant-owned numbers; the UCaaS adapters inherit the vendor-side attestation. The posture matters because downgraded calls get Scam Likely treatment on modern carrier networks.

A-level attestation

Strkr Messaging signs on origination.

Outbound calls from Strkr Messaging-owned numbers carry A-level STIR SHAKEN attestation (the carrier attests to full knowledge of both the caller identity and the right to use the originating number). Pickup rates on modern Verizon, AT&T, and T-Mobile networks run roughly 15 to 25 percent higher on A-attested calls versus unattested legacy traffic.

Pool hygiene

Flagged numbers rotate out automatically.

Carrier feedback loops publish spam-score signals back to the originating pool. A flagged DID drops into a cooldown window of about three days, cycles through a diagnostic re-test on a clean inbound batch, then either rejoins the dial rotation or retires permanently. Rep queues never surface a quarantined number. The entire discipline sits inside the platform rather than inside a RevOps weekly spreadsheet.

DNC enforcement

Federal, state, and tenant internal.

The telephony layer enforces three DNC lists before dialing: federal registry (updated nightly), state registries for jurisdictions with tenant presence, and the per-tenant internal suppress list. A dial attempt against any list drops before signalling. The suppress list honors a 60-second propagation SLA across all active rep queues.

Two-party consent

Recording announcements per region.

Regions with two-party consent requirements (California, Florida, Illinois, several others; most of Europe) trigger a pre-recorded consent announcement on connect or an inbound-ring consent prompt before recording starts. The consent event logs per call; the audit log carries the announcement that played. Server-side enforcement; rep handset actions cannot bypass.

HIPAA posture

BAA covers telephony data path.

Call metadata, recordings, and transcripts fall under the standard Strkr BAA for healthcare tenants. The CTI layer never writes PHI to logs; recordings encrypt at rest with tenant-specific keys through AWS KMS. Access to recordings respects the standard permission matrix; a rep without the view-recording permission cannot pull audio even for calls they placed themselves.

SOC 2 Type II

In progress through 2026-Q4.

SOC 2 Type II audit, in progress through 2026-Q4, covers the telephony stack identically to the rest of the platform. Change management, access reviews, encryption key rotation, and incident response procedures are audited across the full CTI layer. Letters of attestation are available on request from the trust center once the audit completes.

Event semantics

Exactly-once, in-order, acknowledged.

A telephony integration that double-logs calls or drops dispositions on reconnect is worse than useless; the record of truth corrupts. The event layer carries three guarantees that make the integration safe in the presence of flaky carrier networks and vendor API quirks.

Exactly-once

A duplicate event is a no-op.

Every event carries a session UUID plus event-type key. The ingestion endpoint applies the key as an idempotency check against a 24-hour sliding window; a duplicate key is logged and discarded. Reps never see a duplicate call row from a vendor retransmission. The guarantee holds across adapter reconnects, webhook retries, and manual replay requests.

Ordering

Ring before Answer before Hangup, always.

Events arrive out of order sometimes (webhook retry windows, vendor-side queue reordering). The event processor buffers for up to five seconds post-arrival and applies strict ordering per session UUID. A late Ring event with an earlier timestamp lands in the right slot. Downstream listeners (screen pop, auto-log, analytics) read from the ordered stream.

Acknowledgment

Vendor sees a 200 only on durable write.

The ingestion endpoint returns 200 OK only after the event lands durably on the Strkr event log. Vendor-side webhook queues treat a non-200 as a retry trigger; the design means a transient Strkr-side failure causes the vendor to retry rather than drop. The acknowledgment behavior is the difference between resilient and fragile under load.

Replay

Historical ranges reprocess cleanly.

An admin can request a replay of a historical event range (common after an adapter-side bug fix or a reconciliation audit). The replay re-emits events into the processor; idempotency and ordering guarantees mean the final state matches the original state. Side effects (screen pop, auto-log) run again where appropriate or skip where not, based on the replay-mode flag.

Backpressure

A slow consumer does not slow ingest.

The event processor and the downstream consumers (screen pop, auto-log, analytics) sit behind a bounded queue. A slow consumer backs up its own queue; it does not block ingest. Reps never see a delayed screen pop because the analytics pipeline is slow. The decoupling matters at high-volume tenants running thousands of calls an hour.

Latency budget

Ring to pop under 400 ms median.

The internal latency budget from Ring event ingest to screen pop render runs at 400 ms median on healthy regions, with a 95th percentile under 900 ms. Breaches trigger an operational alert and surface on the tenant admin dashboard. The budget is the metric the engineering team tunes against; vague fast promises are not useful at the integration layer.

Screen pop internals

How the record appears before the rep says hello.

Screen pop is the user-facing moment of a telephony integration. Done well, the rep answers with context. Done poorly, the rep answers with sorry, who is this again while the record loads for ten seconds. The internals matter.

Persistent websocket

The rep client holds a live channel.

Every logged-in rep session holds a persistent websocket to the Strkr backend. The channel multiplexes record updates, chat notifications, system messages, and screen pop RPCs. The pop ride on the same channel so there is no extra connection to establish; the rep client is ready for a pop the moment they land on any page.

Pop payload

Record ID, snapshot, deep link.

The pop payload carries the matched record ID, a snapshot of the key fields (name, title, company, last activity, open opportunities), and a deep link to the full record detail. The snapshot renders instantly; the full detail loads if the rep clicks through. The two-level design keeps the pop fast and the context useful.

Multi-session

Pop appears on the active rep surface.

A rep logged in on a desktop browser and a mobile app sees the pop on whichever surface has recent activity. If both are active, both render. The design matches how reps actually work: at the desk for office hours, on mobile for after-hours inbound. No rep misses a pop because they were on the wrong device.

Idle-state pop

Rep away from screen gets a browser notification.

A rep who stepped away receives a browser notification (desktop OS native) on inbound ring. Tapping the notification focuses the Strkr tab and surfaces the pop. Reps on mobile get a push notification through the Strkr mobile app. The screen pop never silently fires into the void.

Multi-match handling

A number on two records surfaces both.

Rare case: one phone number maps to two records (shared office line, portfolio contact). The pop renders a chooser rather than guessing. The rep picks the right record in two seconds; the auto-log then binds to the chosen record. The chooser is tenant-configurable to prefer a record type (lead over contact, or vice versa) when the choice is unambiguous for the team.

Pop audit

Every pop writes an event.

The screen pop event itself writes to the audit log: timestamp, rep, record ID, pop latency, whether the rep clicked through or dismissed. A manager auditing why a rep missed context on a bad call can see whether the pop fired, whether it rendered, and whether the rep acknowledged. The audit trail covers the integration itself, not just the business event.

Open contract

Build your own adapter if the shipped list is wrong.

For teams on an unusual phone system (self-hosted PBX, acquired niche vendor, legacy on-prem Cisco UCM), the open CTI contract is the escape hatch. The contract is a lightweight REST plus webhook spec. A small integration team ships a custom adapter in days, not quarters.

OpenAPI 3.1

The spec lives on the trust center.

The telephony ingest API is documented in OpenAPI 3.1 at the Strkr trust center. Endpoints cover event emission (POST per lifecycle event), record correlation lookup (GET for pre-call pop prep), and recording upload (POST with multipart on hangup). Schemas are versioned and backward-compatible across major releases.

SDKs

Node, Go, Python shipped.

The telephony SDKs cover the common languages for adapter authors. Each SDK ships event-emission helpers, signing primitives for the webhook auth header, and local-mode tooling for adapter development against a mock Strkr endpoint. The SDK lives on the Strkr GitHub org under an MIT license.

Webhook signing

HMAC with rotating tenant keys.

Inbound webhooks from a custom adapter carry an HMAC signature in the Authorization header, computed from a per-tenant signing secret. The secret rotates on a tenant-controlled schedule; grace windows for in-flight events last 24 hours. The signature prevents forged events from unknown callers.

Rate limits

Per-tenant burst and sustained.

The ingest endpoint enforces per-tenant rate limits with burst and sustained ceilings. A tenant running a large parallel-dial sweep can burst to 500 events per second for 30 seconds and sustain 100 events per second indefinitely. The limits sit above typical telephony volume by a wide margin; limit hits almost always indicate a bug on the adapter side.

Test tenants

A sandbox tenant for adapter development.

Each production tenant can spin up a free sandbox tenant for adapter development. The sandbox mirrors the production API without consuming production events. Adapter authors test full lifecycle flows (ring, answer, record, hangup, pop) before pointing the adapter at the production tenant. The sandbox lives for 90 days per spin-up and recycles on tenant request.

Partner certification

Published adapters land on the marketplace.

Partners who build an adapter against the open contract can submit for certification. Certified adapters land on the Strkr marketplace with a verified-partner badge; tenants install from the marketplace with the standard OAuth setup. Certification covers event-ordering correctness, idempotency, failure recovery, and auth hygiene. The lane is open to anyone, not gated behind a tier.

Thirty-minute technical deep dive on the CTI stack.

Bring your telephony admin and your network engineer. We will walk the SIP signalling, the WebRTC media, the screen pop RPC, and the audit log, with your actual vendor on screen.

Book a technical demo See phone system adapters
Common questions

What buyers ask about this feature.

Does Strkr act as a carrier or route through a carrier?

Strkr Messaging operates as a tier-one wholesale carrier integration (through Bandwidth) for tenants on the native path. For UCaaS adapter paths across the supported vendor list, the carrier role sits with the UCaaS vendor; Strkr acts as the CTI listener and the record of truth. Both modes coexist in a single tenant: some teams run on Strkr Messaging while others continue on an existing UCaaS contract, without conflict in event handling or reporting.

What is the SIP trunk requirement for self-hosted PBX scenarios?

For self-hosted PBX (Asterisk, FreeSWITCH, Cisco UCM), the tenant builds a lightweight adapter that listens to SIP INVITE and BYE events on the PBX side and forwards canonical CTI events to the Strkr webhook endpoint. The adapter runs on the tenant infrastructure; Strkr does not terminate SIP directly. Example adapters for Asterisk and FreeSWITCH are on the Strkr GitHub org under MIT license.

How do you handle a call that spans multiple carriers (SIP federation)?

A call that crosses carrier boundaries (common on federated SIP paths) produces one or more session UUIDs depending on which legs the primary adapter sees. The event processor correlates by caller-ID plus timestamp overlap to merge related sessions into one logical call thread; the audit log preserves each leg separately for compliance. The behavior matches enterprise SIP peering practice.

What is the latency from a vendor webhook arriving to a screen pop rendering?

Internal latency budget from webhook ingest to screen pop render runs at 400 ms median on healthy regions, with 95th percentile under 900 ms. Variance comes mostly from client network RTT; the server-side portion (record lookup plus channel broadcast) stays under 150 ms at the 95th percentile. The budget is the metric the engineering team monitors; breaches surface on the operational dashboard.

Can we export the raw CTI event stream for compliance archive?

Yes. The telephony event log is exportable via the standard activity export API, with filters by date range, event type, user, and record. Exports stream as newline-delimited JSON for ingestion into SIEM or compliance archive systems (Splunk, Datadog, Chronicle, Elastic). The event schema is stable across major releases; downstream parsers do not break on routine platform updates.

How does WebRTC work in a corporate network with strict firewall rules?

The native WebRTC path uses STUN and TURN servers for NAT traversal; the TURN relay runs on standard ports (443 TCP and UDP) to pass through most corporate firewall postures. For networks that strictly block UDP, the fallback is TURN over TCP on 443, which works through almost any proxy. A small set of enterprise environments requires an explicit allowlist for the Strkr media relay IP range, which is published in the trust center.

Related features

Pair this with...

CRM Phone Integration CRM Phone System Integration CRM Dialer CRM SMS Integration Activity Tracking CRM Office 365 Integration

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing