CALL PROVIDER
Keep your phone system. Connect it to AlefOS.
For Team telephony, AlefOS can work around a compatible existing provider, a supported WebRTC system or a dedicated PBX/telephony deployment. The phone system keeps handling calls. AlefOS keeps the supported customer context, call evidence and next work around them.
The provider carries the call. AlefOS keeps the operational continuity.
Team call operation
DeploymentProvider
Carry calls, numbers and routing.
Verify
Expose usable events and artifacts.
Continue
Keep authorized context and next work available.
Do not replace a working phone system without a reason.
Existing numbers, routing, agents, queues, recordings and provider contracts can remain in place only when the current provider exposes the events, identity and artifacts AlefOS needs. If that compatibility is absent, a WebRTC or PBX deployment is a scoped technical decision—not a universal fallback promise.
Choose the path that matches the current environment.
The three possible paths are an existing provider, a supported WebRTC call flow or a dedicated PBX/telephony deployment. The right path depends on current provider, countries, routing, call volume and available data.
1. Existing provider
Use the provider already carrying company calls when its configured integration exposes required data.
2. WebRTC system
Deployment-dependent until the complete call, artifact and production path is verified.
3. Dedicated PBX / telephony
A scoped architecture for numbers, queues, extensions, routing and recording policy.
Connect the provider you already use — when it exposes what AlefOS needs.
Aircall has a registered webhook adapter. It resolves an active tenant connection from a webhook secret, requires a stable provider call ID for completed calls, and can use available provider transcript data in the call pipeline. This is a configured deployment path, not proof that every Aircall account, event, recording or transcript is enabled. No other external provider is named here as a live AlefOS integration.
Aircall
Registered webhook adapter; active tenant connection, webhook authorization and provider data remain required.
Other providers
No other external provider is named here as a live AlefOS integration.
Provider data
Lifecycle events, identity and usable recording or transcript paths must be proven per deployment.
Use a supported WebRTC call flow when the browser or app is the phone surface.
The repository exposes authenticated SIP/WebSocket configuration only when its required secrets are present. This branch does not prove the complete Team WebRTC lifecycle for browser or mobile calling, routing, recording, transcript and production deployment. WebRTC therefore remains deployment-dependent.
Scope a dedicated phone architecture when the workflow needs it.
Telnyx and FreePBX webhook and call-control modules exist for CallOS-related rails. Their presence does not prove a self-service Team PBX offer, universal SIP compatibility, number ownership transfer or a deployed customer telephony architecture. A dedicated numbers, queues, extensions, routing or recording-policy design requires a scoped deployment review.
A logo is not an integration.
AlefOS needs reliable lifecycle events, caller/callee and agent mapping, stable source IDs, a permitted recording or transcript path where relevant, webhook authentication, deduplication, retries, durable storage, compatible region and retention rules, and explicit provider error states. Compatibility is proven by available data and control, not by a provider name alone.
Keep call context at company level.
When the configured provider supplies usable data, AlefOS can preserve company call history, authorized Contact linkage and available transcript or summary references. That context can inform a supported Mission, next work, ownership or handoff. Provider evidence remains distinct from derived AlefOS context, and no artifact is promised for every provider event.
Provider evidence
Lifecycle data and artifacts from the configured provider.
AlefOS context
Authorized relationship, history and derived work context.
Next work
A Mission or handoff only where its supported action contract applies.
The company should keep control of its phone operation.
Provider contract, number ownership, routing and recording policy remain explicit. AlefOS does not silently port numbers or assume control of provider accounts. Team access continues to follow current role, assignment and object scope; credentials and provider secrets are never public.
Selective capture and systematic telephony solve different problems.
CallOS is the selective, individual professional-call flow. Call Provider is the configured company/provider path for systematic supported Team telephony. Occasional important calls point to CallOS. Company-wide call operations require Call Provider deployment.
CallOS
One professional and selectively chosen calls.
Call Provider
Company/provider deployment and systematic supported Team calls.
Call state, AlefOS state and provider state can differ.
A completed call can arrive late by webhook; an event can be stored while a recording is unavailable; metadata can exist while a transcript fails; a Contact can link while a provider artifact is missing; and a Mission can be prepared without confirmation. The public status must preserve those distinctions instead of flattening them into “captured.”
Webhook delayed
The call may be complete before an event reaches AlefOS.
Artifact missing
Metadata can exist without a recording or transcript.
Derived work pending
A prepared Mission is not a confirmed or executed action.
Systematic capture requires explicit company rules.
Which calls are included, who is notified, recording and consent requirements, retention, access to recordings or transcripts, and employee-departure handling remain company, provider and applicable-jurisdiction decisions. This page makes no universal recording-law or retention guarantee.
Verify the current phone environment before promising the connection.
1. Audit provider, numbers, countries, queues, agents, routing, recordings and APIs. 2. Choose existing provider, WebRTC or dedicated PBX. 3. Agree permission and retention rules. 4. Connect only the verified provider-specific path. 5. Test lifecycle events, identity, artifacts and failure states. 6. Roll out only within the agreed deployment scope.
Keep the phone system where it works.
Connect only what is compatible. Preserve company ownership. Let AlefOS keep the supported call context and next work. No universal provider promise is made.
FAQ
Answers reflect the current provider, deployment and permission boundaries.
What is Call Provider?
Call Provider is AlefOS documentation for a configured Team telephony connection. The phone system carries calls; AlefOS can preserve only the supported, authorized call context around them.
Does AlefOS replace our PBX or carrier?
No. Provider contracts, numbers, routing and the phone operation remain explicit. AlefOS does not silently port or take ownership of numbers.
Can we keep our current provider?
Only where the provider exposes the events, identity and artifacts required for the agreed deployment. Compatibility is assessed per provider and configuration.
Which providers are supported?
Aircall has a registered webhook adapter and active tenant-connection checks. This page does not name other external providers as live integrations.
Is Aircall supported?
Aircall can be used through its registered webhook path when the tenant connection is active, the webhook is authorized and the relevant provider data is available. That remains configuration- and deployment-dependent.
Does AlefOS support WebRTC?
The repository exposes authenticated SIP/WebSocket configuration when required secrets are present, but this branch does not prove a complete Team WebRTC calling, recording and transcript deployment.
Can AlefOS deploy a PBX?
Telnyx and FreePBX modules do not establish a self-service or universally deployed PBX offer. A PBX architecture requires scoped deployment review.
Who owns the numbers?
Number ownership and provider contracts remain explicit with the company and provider. AlefOS does not claim to port or take over numbers automatically.
Does every call get recorded or transcribed?
No. Available recording and transcript artifacts depend on the provider, configuration, permission and applicable rules.
Can calls link to Contacts or Missions?
Available call context can link to Contacts and inform supported Missions or next work when identity, source, scope and permissions support it. Neither link is guaranteed for every call.
What happens when provider artifacts fail?
Call completion, webhook ingestion, recordings, transcripts, Contact linkage and Mission preparation can succeed or fail independently. AlefOS should report the actual state rather than imply complete capture.
Can managers see every recording or transcript?
No. Access follows the current Team role, assignment and object scope, plus provider and retention rules.
How is Call Provider different from CallOS?
CallOS is selective capture for one professional’s chosen calls. Call Provider is the configured path for systematic supported Team telephony.
Is recording compliant everywhere?
No universal compliance claim is made. Company, provider, country, region, consent and legal requirements remain authoritative.
How does deployment work?
AlefOS first audits the phone environment, chooses a compatible path, agrees policies, tests lifecycle and failure states, then rolls out within an agreed scope.
Choose your next step
Build shared memory around the way your company already works.
Talk with AlefOS about users, permissions, providers and the first deployment workflow to connect.