For whom is CodeB Conference?
Six audiences who get value from CodeB today. For each: the problem they walk in with, the CodeB answer, why Zoom or Teams isn’t the right fit, and the deployment model that matches.
Privileged communication, on infrastructure you control.
The problem
Attorney-client privilege does not survive a vendor with overbroad data-processing terms. Discovery requests against the cloud video provider can erode confidentiality. Recorded depositions need defensible chain-of-custody — an unsigned MP4 from a cloud product is hard to authenticate in court.
The CodeB answer
The meeting platform runs on the firm’s own server. Media is peer-to-peer between participants with DTLS-SRTP encryption; nothing goes through a cloud media path. Every local recording carries an ECDSA-P256 cryptographic signature in a tamper-evident sidecar — a third party can verify the recording was not altered between capture and trial.
Why not Zoom / Teams
Both run media through vendor-managed cloud infrastructure with admin-analytics surfaces accessible to the vendor. Recordings are not cryptographically signed. Data-processing terms include broad rights to operational data the firm cannot fully audit.
Deployment
Single Windows server on-premise or in the firm’s private hosted tenant. SSO via the firm’s existing identity store (Active Directory / OIDC). Air-gappable for matter-isolated deployments.
Telemedicine without sending PHI to a SaaS cloud.
The problem
Patient health information is regulated — GDPR Art. 9, HIPAA in the US, equivalent regional law elsewhere. Cloud video tools shift the controller/processor boundary in ways that make procurement and legal review expensive. EU healthcare providers face additional Schrems II concerns about US-hosted providers.
The CodeB answer
Patient audio and video never reach a third party. Meetings run on the clinic’s own server (or a private hosted tenant in a chosen jurisdiction). End-to-end DTLS-SRTP encryption between clinician and patient browsers. Retention is set by the clinic, not by the vendor; signed local recordings give a defensible audit trail.
Why not Zoom / Teams
Both require a BAA / DPA for healthcare use. Both add admin-analytics surfaces and metadata flows the clinic cannot fully suppress. Teams is welded to M365; using it for patient encounters drags the rest of the M365 estate into scope for healthcare-data review.
Deployment
On-premise Windows server in the clinic, or a private hosted tenant in the clinic’s jurisdiction. SSO against the clinic’s existing identity store. Optional CodeB Voice AI for appointment reminders — with on-premise AI Voice Engine fallback for clinics that cannot send caller audio to a cloud model.
Procurement-friendly. Air-gappable. Auditable.
The problem
Government and public-sector buyers face third-country-transfer rules, sovereignty-cloud requirements, fixed-budget cycles that don’t map well to per-seat SaaS, and auditor demands for source-level review of any system handling official communications. Most cloud video products fail at least two of these tests.
The CodeB answer
Runs entirely on the agency’s own Windows + IIS server. No hyperscaler dependency. Source code is open to inspection inside the customer’s organisation — auditors can read every C# handler, every JavaScript file, the entire TURN service. Air-gap deployment is supported with all dependencies served locally.
Why not Zoom / Teams
US-hosted by default; data residency in EU regions exists but doesn’t address Schrems II concerns. Per-seat licensing creates an annual budget line that recurs forever. Source is not available for audit. Many EU public-sector bodies have explicit guidance discouraging both.
Deployment
On-premise Windows server inside the agency’s network. Optional air-gap mode — fonts, signaling, TURN, ML models all served from the LAN. Single capex line item; no recurring per-seat fees.
Front-desk telephony in a browser, AI after hours.
The problem
Hotel reception desks need a phone that lives in the front-desk browser tab, rings on the hotel’s SIP trunk, and doesn’t require a separate hardware phone or a SaaS UCaaS contract. After-hours coverage needs an AI receptionist that can take a reservation request or route urgent calls to the duty manager — without paying a third-party answering service.
The CodeB answer
The CodeB Phone PWA installs once on the front-desk computer and behaves like a desk phone — ringing on incoming calls, OS-level notifications, click-to-call. The CodeB Voice AI handles after-hours inbound: per-DID persona prompts, transfer to duty-manager mobile if the caller says "urgent," signed transcripts emailed to the manager next morning. Outbound AI can run wake-up calls.
Why not Zoom / Teams
Zoom Phone and Teams Phone bundle their own carrier service — the hotel already has a SIP trunk and doesn’t need a second one. Neither product’s AI assistant covers after-hours reception with a per-DID persona out of the box.
Deployment
Single Windows server on the hotel’s network or hosted by an IT partner. Registers as a SIP user on the hotel’s existing PBX (FRITZ!Box, 3CX, Yeastar, Asterisk, anything that speaks SIP). Front-desk staff just open the bookmark; no install for participants.
A turnkey video + AI voice layer for your existing PBX practice.
The problem
IT providers and MSPs who run PBX deployments for customers already have a SIP estate they manage. They’re losing video-meeting revenue to Zoom and Teams, and AI-voice revenue to standalone receptionist startups. Building either in-house is months of work; reselling someone else’s SaaS means margin sharing and no differentiation.
The CodeB answer
Deploy CodeB per-customer on Windows + IIS as a managed add-on. Customers get browser meetings, signed recordings, AI receptionist and outbound AI campaigns — all on the SIP trunk the reseller already manages. The reseller bills the customer for the deployment and ongoing operation; no per-minute margin shared with a SaaS vendor.
Why not Zoom / Teams
Both are direct-sale products; reseller margin is thin or non-existent. Neither integrates cleanly with the SIP trunks the reseller is already managing — they bring their own carrier service. No source access means the reseller can’t customise per-customer.
Deployment
Per-customer Windows + IIS install, often co-located with the customer’s PBX. The reseller may run multiple tenant deployments from one hosted Windows server (multi-tenancy by domain is the supported topology). White-label branding via per-tenant CSS.
Layer on. Don’t rip and replace.
The problem
The organisation already paid for its PBX. SIP trunks, extensions, call routing, voicemail — all working. What’s missing is modern web video, browser-based softphones for hybrid workers, optional AI receptionist on the inbound DID. Rebuying the entire telephony stack to add a video layer doesn’t make budget sense.
The CodeB answer
CodeB is a SIP client / bridge — it registers against the existing PBX as a regular SIP user (or multiple users, one per CodeB Phone account). The PBX stays in charge of routing, voicemail, recording policies. CodeB adds browser meetings, click-to-call, AI receptionist on top, without touching what already works.
Why not Zoom / Teams
Zoom Phone and Teams Phone want to replace the PBX with their own carrier service. For an organisation that already paid for FreePBX, 3CX, Asterisk or a FRITZ!Box, that’s a parallel telephony stack at extra cost. CodeB does the opposite — it integrates with what’s already there.
Deployment
One Windows + IIS server alongside the existing PBX. Configure CodeB’s SIP trunks to point at the PBX’s SIP interface. Tested against FRITZ!Box, 3CX, Asterisk and FreePBX; any standards-compliant SIP gateway should work. See the comparison page for a feature matrix.
Not sure which path fits?
If your organisation isn’t a clean match for any of the six above, we’re probably still useful — the underlying primitives (BYOC SIP, browser WebRTC, OIDC, voice AI) compose into a lot of shapes. A 30-minute call is faster than reading the rest of the site.
Talk to us