LiveKit Telephony

# Fix list: LiveKit Telephony

From Anchor Terminal's listing at https://www.anchorterminal.com/tools/livekit-telephony, the October 2026 research run, assessed 8 October 2026. Grade B, 67.5 out of 100.

This is everything the published grade says the listing lacks, the biggest possible gain to the total first. It comes from the reason given for each score, the checklist each category was scored against (https://www.anchorterminal.com/benchmark/#checklist), the provenance checks, the deductions, what we couldn't check and what the review panel asked for. A fix counts at the next check, once it's public.

For a coding agent working on LiveKit Telephony: work through the items below in the product, its docs and its public pages. Each category gives the reason for its score, with the points each checklist item earned, and the checklist itself, so the gap is the items that earned less than their points. Change the product, not the wording, and keep a note of what you changed and where it's published.

## 1. Payments & pricing, 40 out of 100, up to 7.5 more on the total

Why it scored 40: No x402, MPP or L402 found (0). Per-minute and per-number prices are public without a login, also as Markdown (20). The Build plan is free with no card and includes a US local number, 50 inbound minutes and 1,000 third-party SIP minutes a month (20). An account is created in a browser and `lk cloud auth` opens one, and no programmatic sign-up or key API was found (0).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-payments):

The published rubric, also on the [x402 page](https://www.anchorterminal.com/x402/).

- 40, a machine payment protocol (x402, MPP or L402) on the tool's own endpoints. 10 to 30 when it covers only some endpoints or only goes through a third party, and the note says which.
- 20, per-call or per-unit pricing published without a login. 10 for public plan-only pricing, 0 for "contact sales" or prices behind a login.
- 20, a free tier or trial that doesn't need a card.
- 20, autonomous onboarding, meaning an agent can get access without a person signing up in a browser (keyless use, x402, a programmatic key API).

Payment platforms and agent wallets rarely charge for their own API over a machine protocol, so the first line has steps for them, and the highest one that applies counts. 40 when x402, MPP or L402 runs on all their own endpoints, 30 when it runs on part of their own API, 25 when their merchants can accept one, 20 for running a facilitator, 15 for paying as a buyer, and 0 when the only protocol is their own. Merchant acceptance sits above a facilitator because the platform's own customers can charge agents through it, while a facilitator settles for sellers who wire up the protocol themselves. The counter-argument (a facilitator does more for the protocol as a whole) has a point. Each note says which step applied.

Open-source software you run yourself is scored on its hosted or paid option if it has one. A free, self-hosted package with nothing to buy gets 20, 20 and 20 for the last three lines, and 0 to 40 for the first only if it ships a payment protocol.

## 2. Reliability, 65 out of 100, up to 7 more on the total

Why it scored 65: Graded as a hosted service, LiveKit Cloud. Statuspage at status.livekit.io with SIP per region, Global SIP and US Phone Numbers as components (20). In the 90 days to 8 October the SIP incidents were all marked minor or none. Failed SIP transfers in US East ran about 72 minutes on 17 August, one-way audio on LiveKit Phone Numbers about 42 minutes on 2 September, and raised API latency on SIP twice on 15 September for about 70 minutes each. The two incidents marked major (2 and 15 September) hit the dashboard, analytics and billing API, not calls (20). The Server API limit is 1,000 requests a minute per project, with number limits of 100 on Ship and 300 on Scale (15). No 429, Retry-After, backoff or idempotency guidance was found for the SIP API (0). The pricing page lists 99.99% uptime for every plan, and section 2.5 of the terms calls such figures objectives with no credits outside a written Enterprise agreement, so no SLA is counted (0). The SIP API carries no beta label, though the warm transfer task in the Agents framework is marked beta, in Python only (10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-reliability):

Hosted APIs, MCP servers, models and platforms.

- 20, a public status page with component history (Statuspage, Instatus, BetterStack or the vendor's own).
- 0 to 30, the incident record for the last 90 days on that page. 30 for a clean record or trivial incidents only, 20 for minor incidents only, 10 for one major outage (an hour or more of a core API down, or errors across the board), 0 for several. 5 when there's no history we could read, and the note says so.
- 15, rate limits documented with numbers.
- 15, documented 429 or overload handling (Retry-After, backoff guidance), and idempotency keys or safe-retry guidance where writes are involved.
- 10, an SLA published for any paid tier.
- 10, the surface agents use is generally available, not beta or preview.

Local packages, SDKs, frameworks and stdio MCP servers.

- 20, installs from an official package with supported runtimes stated.
- 25, a public CI and test suite, passing on the default branch.
- 0 to 25, open crash or regression issues relative to activity (25 for few and handled, 0 for many, old and unanswered).
- 15, semver discipline and breaking changes called out in a changelog.
- 15, version 1.0 or later, or declared stable.

Protocols are read from their reference implementations, the public facilitators or servers, spec stability and test vectors.

## 3. Security & auth, 61 out of 100, up to 6.8 more on the total

Why it scored 61: A project key and secret sign JWTs whose `sip` grant is `admin` or `call`, with a lifetime the signer sets. Keys rotate in the dashboard. The key pair itself can mint any grant, so scoping depends on the operator handing an agent a token and not the secret (25 of 30). `call` without `admin` is a least-privilege mode for dialling, inbound trunks can be limited by number, IP range or credentials, and no read-only grant or confirmation step for dialling or renting numbers was found (8 of 20). Calls carry untrusted caller speech, and no prompt-injection guidance was found in the telephony docs (5 of 15). The security overview says project configuration changes are logged, with export to a SIEM still on the roadmap, and the dashboard shows call logs (8 of 15). security.txt with a disclosure policy and safe harbour, a Hall of Fame with no cash bounty stated, SOC 2 Type II, six-monthly penetration tests, ISO 27001 in progress, and no published advisories on livekit/sip, livekit/livekit or livekit/livekit-cli (15 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-security):

- 0 to 30, the credential model. 30 for OAuth 2.1 with scopes, or scoped and revocable keys with rotation. 20 for plain revocable API keys. 10 for one all-powerful key. 10 off when a secret can travel in a URL query string as a documented option.
- 0 to 20, read-only or least-privilege modes, and confirmation or approval for destructive actions.
- 0 to 15, prompt-injection posture where the tool returns untrusted content (documented mitigations or guidance). A tool that returns no untrusted content gets 10.
- 0 to 15, audit logs or per-call visibility for the operator.
- 0 to 20, a security programme. security.txt or a disclosure policy, a bug bounty, SOC 2 or ISO 27001, advisories handled in public.

Models are read for retention, whether API data trains models (and whether that's off by default), zero-retention options and certifications. Frameworks for telemetry defaults, approval hooks, guardrails and sandboxing.

## 4. Agent ergonomics, 66 out of 100, up to 5.5 more on the total

Why it scored 66: List calls take a limit and ID, number or status filters, with no field selection (15 of 25). A `Pagination` type with `after_id` and `limit` on the SIP list calls (18 of 20). `wait_until_answered` returns a `SipCallError` with the carrier's SIP status code, and the docs map codes to outcomes. Twirp errors are named only in passing (15 of 20). No idempotency key was found, so a retried `CreateSIPParticipant` can place a second call (3 of 20). A call needs a trunk, a number and a room name, and SIP clients ship in Go, JavaScript, Python, Ruby, Kotlin and Rust plus the `lk` CLI (15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-ergonomics):

- 0 to 25, context cost. For MCP, the number and size of the tool definitions (25 for ten or fewer compact tools, 15 for 11 to 30, 5 for more than 30, plus up to 10 back for toolsets, dynamic loading or read-only subsets). For APIs, whether responses can be sized (field selection, limits, summaries).
- 20, pagination, filtering and output-size controls.
- 20, actionable, documented error responses, codes and messages an agent can recover from.
- 20, idempotency or safe retries, and for MCP the `readOnlyHint` and `destructiveHint` annotations.
- 15, sensible defaults, few required parameters, and official SDKs in at least two languages.

Models are read for tool use, structured output, prompt caching, context length, batch and SDKs. Frameworks for how much code and how many defaults a tool-calling agent with MCP needs.

## 5. Schema & documentation, 84 out of 100, up to 2.6 more on the total

Why it scored 84: The contract is protobuf in livekit/protocol (17 SIP RPCs, 6 phone number RPCs), called as JSON over Twirp. No OpenAPI document was found, and we counted the protobuf files as the similar spec (25). llms.txt per docs section and every page as Markdown (10). Reference tables give each parameter's purpose, and the guides say when to use an inline trunk or a stored one (15 of 20). Typed fields with enums for transport, encryption and number status and required fields marked, with metadata as a free string (13 of 15). Examples in six languages and the CLI, a call outcome table and a troubleshooting guide by SIP code. No full list of Twirp errors was found, and the reference still shows `TransferSIPParticipant` returning an empty message where the protocol changelog says it now returns a response object (11 of 15). The Twirp path has no version. Changes are dated in livekit/sip release tags and the protocol `CHANGELOG.md`, with no cloud changelog page found (10 of 15).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-schema):

APIs and MCP servers.

- 25, a machine-readable contract (a public OpenAPI file or similar; for MCP, typed JSON Schema inputs on every tool).
- 10, llms.txt or Markdown docs served for agents.
- 0 to 20, descriptions that say what a tool is for, when to use it and when not to, read from the tool definitions in the source or the API reference.
- 0 to 15, typed inputs with enums, constraints and required fields, and no free-form JSON blobs.
- 0 to 15, examples and documented error responses.
- 15, versioning and a public changelog.

Models are read from the API reference, the OpenAPI file, llms.txt, the structured-output and tool-use docs and the model cards. Frameworks from docs a model can follow, typed interfaces, examples and the API reference.

## 6. Transparency & trust, 75 out of 100, up to 2.2 more on the total

Made of editorial 69, provenance 81.

Why it scored 75: The SIP service, protocol, CLI and SDKs are Apache 2.0, and the security page says the same code runs on LiveKit Cloud. The cloud control plane and LiveKit Phone Numbers are closed, under clear terms (25 of 30). Terms, privacy policy and DPA all dated 6 October 2026 agree. The DPA lists retention by data category, user content is deleted after delivery unless recording is on, telemetry is kept up to 60 days and backups up to 30. Call detail records have no fixed period, and the sub-processor list names no telephony carrier for LiveKit Phone Numbers (22 of 30). No deprecation policy was found. Deprecated fields are flagged in the reference without dates, and the terms give 30 days' notice of changes to the agreement (5 of 20). The sub-processor list gives each entity, its activity and its country, all in the United States, with a way to subscribe to changes, and the docs list the SIP regions (17 of 20).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-transparency):

- 0 to 30, source availability and licence clarity. 30 for open source under an OSI licence, 15 for closed with clear terms, 0 for unclear terms.
- 0 to 30, data handling and retention statements that agree with each other (privacy policy, DPA, retention periods, subprocessors).
- 0 to 20, a deprecation policy or notices with dates.
- 0 to 20, telemetry disclosed with an opt-out (local software), or subprocessors and data locations disclosed (hosted).

The other half of Transparency and trust is the provenance score, computed from checked facts (below). The category score is the mean of the two.

Provenance checks not met in full (half of this category, computed from checked facts):

- Endpoint on the vendor's domain:  is not on livekit.com (0 of 15)
- Terms of service: read, states 6 of the 7 things a reader expects, and has 1 clause that costs points (7.1 of 10)
- Privacy policy: read, states 6 of the 8 things a reader expects (8.5 of 10)

## 7. Maintenance & community, 90 out of 100, up to 0.9 more on the total

Why it scored 90: livekit-cli v2.19.0 was tagged on 8 October 2026 and livekit/sip v1.18.0 on 5 October (30). livekit/sip has 12 tags from v1.7.0 on 10 July to v1.18.0 (20). Of the 30 newest open issues and pull requests on livekit/sip, 22 have at least one comment. We read the counts and not who replied. Paid plans add email support and there is a community Slack (17 of 25). Current server SDKs, with livekit-server-sdk 2.19.1 on npm and livekit-api 1.2.1 on PyPI from 27 August 2026 (15). livekit/sip runs unit tests with the race detector and integration tests in CI and has Renovate configured. We did not see the latest run's result (8 of 10).

The checklist (https://www.anchorterminal.com/benchmark/#checklist-maintenance):

- 0 to 30, time since the last release, or the last published model or API change for a closed service. 30 within 30 days, 20 within 90, 10 within 180, 0 older.
- 20, at least three releases or dated changelog entries in the last 90 days.
- 0 to 25, responsiveness. Issues and pull requests answered on GitHub (the open issues and how recent the replies are). For closed services, a public changelog and a support or community channel that answers, 0 to 15.
- 15, presence in the official MCP registry under a verified namespace (MCP servers), or current official SDKs (APIs and models).
- 10, package health, current dependencies and CI.

Models are read for deprecation notice periods and model churn rather than release counts.

## What we couldn't check

What we couldn't read counted as absent. Publishing it on a page a plain HTTP fetch can read (not only in a browser) lets the next check count it.

- The lead gave livekit.io as the vendor's site. It now redirects to livekit.com, and the listing uses livekit.com
- Which carrier supplies LiveKit Phone Numbers. The sub-processor list of 10 September 2026 names none
- Whether unanswered or failed outbound attempts count as billed SIP minutes
- How long call detail records are kept. The terms say as long as law or carrier rules require
- Whether the SIP API returns 429 with a Retry-After header at the 1,000 requests a minute limit. No call was made to the API
- unchecked: trust.livekit.io, where the SOC 2 report and penetration test summaries sit behind an NDA request
- unchecked: the Enterprise agreement and its support and uptime SLA, which are not published
- unchecked: who answered the open issues on livekit/sip, and whether the latest CI run on its default branch passed
- unchecked: the Egress docs for recording a SIP call, so `voice.recording` is left out of the capabilities
- The npm and PyPI download counts are for the whole server SDKs, not for SIP use

## Weaknesses

- LiveKit Phone Numbers are US only and inbound only, and `TransferSIPParticipant` does not work on them yet
- Outbound calls need a trunk from another carrier, billed by that carrier on top of LiveKit's SIP minutes
- No 429, Retry-After or idempotency guidance was found for the SIP API, so a retried `CreateSIPParticipant` may dial twice
- The 99.99% uptime on the pricing page is an objective only, with no credits outside a written Enterprise agreement
- Sign-up and `lk cloud auth` need a person in a browser, and no machine payment protocol was found
- The terms bar benchmarking for competitive purposes without written consent

## What costs an agent a turn today

The notes we give agents before they call it. Each one is a workaround an agent shouldn't need.

- Ask the operator for a short-lived token with only the `sip.call` grant to dial or transfer. Trunk, dispatch rule and number changes need `sip.admin`
- Use a third-party outbound trunk for outbound calls. LiveKit Phone Numbers only receive calls
- Set `wait_until_answered` on `CreateSIPParticipant` and read the SIP status on `SipCallError` before retrying. Voicemail answers with 200 OK
- Send every request as a JSON POST to `/twirp/livekit.SIP/<Method>` or `/twirp/livekit.PhoneNumberService/<Method>` on the project's own host, with `{}` for an empty body
- A released number is billed for the whole month, and the free Build allowance is a hard cap after which requests fail

## When it's done

Send what changed and where it's published as a dispute (https://www.anchorterminal.com/builders/#disputes, or `POST https://www.anchorterminal.com/api/v1/contact` with `"kind": "dispute"`). Disputes are answered in public, and the listing is checked again by the same checklist. Paying for an audit or a listing claim changes nothing here.