You want your own application — an agent workstation, a CRM screen-pop, an ISV integration — to drive calls on the platform: originate them, hold and transfer them, set an agent ready or not-ready, or act as the routing brain that decides where a call goes. That is third-party call control, and TeleQuick Voice exposes it as an engine-native ECMA CSTA verb API that your app speaks over the same connection as the rest of the SDK. You do not proxy these actions through the portal or scrape a UI. Your app opens a control leg straight to the engine, authenticates once, and then issues standard CSTA operations — makeCall, holdCall, singleStepTransfer, setAgentState, and the rest — as short request/reply lines. State changes come back to you as a live event stream.

What CSTA is

ECMA CSTA (Computer-Supported Telecommunications Applications, standardized as ECMA-269) is the long-established vendor-neutral API for third-party call control. It defines the operations an external application uses to observe and manipulate calls and agents on a telephony system — make a call, clear a connection, hold, retrieve, transfer, consult, set agent state, register as a route point — without owning the media itself. TeleQuick implements those operations as wire verbs on a control leg into the engine. The verb names map one-to-one to CSTA operations, so if you have driven CSTA before, the model is familiar: your app sends a verb and gets a reply, and separately subscribes to a stream of CSTA events describing what happened to the calls and agents you touched.
This is the engine twin of the routing engine the operator console uses for its own agent workstation. Both surfaces speak the same verbs. The console drives its built-in workstation; this API is for your external ISV or SDK client. There is no behavioral fork — the same call control, exposed for third parties.

When to use it

Third-party call control

Your backend or app needs to originate, hold, transfer, or clear live calls programmatically — not run the AI pipeline, but control the call.

Agent workstations

You are building a custom softphone or agent desktop and need to set agent work state (ready / not-ready / after-call-work) and pop calls on screen.

Route point / ACD brain

Your app registers as a route point and makes the routing decision — receiving route requests and selecting the destination, ACD-style.

CRM / ISV integration

You are integrating an existing contact-center or CRM product and want a standards-based CTI link rather than a proprietary one.
If instead you want the AI runtime to handle a call (ASR/LLM/TTS, speech-to-speech), that is the Runtime, not CTI. CTI sits above the media plane and moves calls and agents around.

Connect

The CTI control leg runs on the engine over one of two transports. Both carry the same length-prefixed, correlated request/reply lines; pick the one that fits your client.
Open a secure WebSocket to the engine with the subprotocol cti. This is the simplest client to write and works from any language with a WebSocket library.
wss://<workspace-id>.webrtc.telequick.dev/    (subprotocol: cti)
Whichever transport you choose, the framing is identical: each message is a length-prefixed line of the form <verb>\t<args-json>, and every request carries a correlation id so its reply can be matched. The very first line you send must be auth — the connection stays unauthenticated (and every other verb is refused) until it succeeds.
1

Mint a CTI token

Ask the control-plane API for a short-lived signed CTI token for the tenant, with the scopes your app needs (see below). Treat it like any bearer credential — it is short-lived by design; refresh and reconnect before it expires.
2

Open the control leg

Connect over cti (wss) or WebTransport /cti as above.
3

Authenticate on the first line

Send auth with the token as the first request. On success the reply confirms the connection and the scopes it was granted; on failure the connection is closed.
First line
auth	{"jwt":"<cti-token>"}
4

Drive verbs and subscribe to events

Issue call-control, agent-state, or routing verbs, and subscribe to the CSTA event track (below) to observe state changes.

Auth and scopes

Authorization is a short-lived signed CTI token minted by the control-plane API. It carries a scopes claim that gates which families of verbs the connection may use. A verb whose scope is not present in the token is refused — request only what your app needs.
call_control
scope
The call-control verbs: makeCall, clearConnection, holdCall, retrieveCall, singleStepTransfer, consultationCall, transferCall, cancelConsultation, generateDigits.
agent_state
scope
Agent work-state control: setAgentState (login / logout / ready / not-ready with an aux reason / after-call-work).
routing
scope
Route-point registration: routeRegister, to receive route requests and select the destination.
Beyond the scope check, per-call verbs are tenant-checked against the call they name — a token for one tenant cannot act on another tenant’s call, even with the right scope. Scopes are additive; a token can hold any combination.

Events ride a durable track

Verbs are request/reply — you send an operation and get an acknowledgement. The resulting state changes arrive separately as CSTA events on a durable cti/<tenant> track that your SDK subscribes to directly. Because the track is durable, a client that reconnects can resume the event stream rather than miss what happened while it was away. The event stream reports the CSTA lifecycle of the calls and agents you touch:
EventMeaning
deliveredA call is offered / ringing at a device.
establishedA connection answered — the parties are talking.
held / retrievedA connection was placed on hold or taken back.
transferredA transfer completed.
clearedA connection was released / hung up.
failedThe operation or call failed.
The pattern is: issue a verb, then watch the event track for the resulting state. For example, makeCall acknowledges immediately, and you learn the far end is ringing via delivered and answered via established.

The verb families

Call Control

Originate, clear, hold/retrieve, blind and consultative transfer, consult, and DTMF — makeCall, holdCall, singleStepTransfer, and the rest.

Agent State

Log agents in and out and move them between ready, not-ready (with an aux reason), and after-call-work with setAgentState.

Routing & Events

Register as a route point with routeRegister and subscribe the cti/<tenant> CSTA event track.
Client surface today. CTI is a wire protocol you speak from any WebSocket or WebTransport client; there is no dedicated single-purpose polyglot CTI SDK wrapper yet. The verbs, framing, auth, and event track documented here are the contract — build against them directly, or over the transport the rest of the SDK already gives you.

High Availability

Run more than one engine node so the CTI control plane and call routing survive a node failure. CTI pairs with the enterprise HA story.

Deployment Models

Where the engine runs — managed cloud or on-prem — and how the control leg reaches it.

On-Prem Quickstart

Stand up the engine in your own environment, the common home for an enterprise CTI integration.

Transport to Telephony

How calls enter and leave over SIP — the calls your CTI app then controls.