Do I need to buy or manage an SBC to use this?

No. SIP.IO's SBC fleet is fully managed: dedicated Teams SBC nodes, per-tenant TLS certificates issued and renewed automatically, and DNS wired up by the platform. Your customer never touches an SBC.

Microsoft Teams Direct Routing

Short answer: SIP.IO runs Microsoft Teams Direct Routing as a fully-managed SBC service: one API call provisions a tenant, issues its certificate, places it on a node, and wires up DNS, so Teams users get PSTN calling through your PBX without anyone buying, racking, or babysitting an SBC. Provision a single tenant for your own organization, one per region or subsidiary if you run several Microsoft 365 tenants, or hundreds for resale as an MSP.

What SIP.IO handles for you

Every item below is normally days of specialist work per tenant, done manually. On SIP.IO it’s automatic and repeats cleanly whether you need one tenant or hundreds:

No hardware. Dedicated Teams SBC nodes (SNI TLS termination, SIP routing, SRTP↔RTP media) are run and monitored by SIP.IO, not you.
Automated certificate lifecycle. Per-tenant RSA certificates (the key type Microsoft’s Direct Routing requires), issued from a public CA, placed on the node, and renewed with zero manual touch.
Bring your own domain. Your own SBC hostname gets a real certificate via ACME-CNAME delegation, no need to hand SIP.IO your DNS credentials, just one delegation CNAME added once.
One account, many SBCs. Running Teams across multiple regions, subsidiaries, or brands? Provision a separate tenant for each, its own PBX, domain, and routing rules, whether that’s your own multi-region rollout or a reseller’s book of customers.
White-label, if you need it. Each brand issues into its own zone, so a reseller’s customers never see a SIP.IO name anywhere in their setup, and MSPs can nest this further under their own brand for their customers.
You keep the routing keys. Point one stable CNAME at a name SIP.IO owns; moving a tenant between nodes or regions is a change to SIP.IO’s own DNS record, your DNS never has to change.

Provisioning a tenant: three API calls

Authenticate with an API key scoped to teams. A real custom-domain tenant, end to end:

1. Create the tenant. Describe the SBC hostname, the brand, and the PBX to bridge to; the response hands back the exact DNS records the customer needs to add.

curl -X POST https://api.sip.io/v1/teams \
  -H 'x-api-key: sk_…' -H 'content-type: application/json' \
  -d '{
    "brand": "sipio", "domain_type": "custom",
    "sbc_domain": "sbc.example.com", "display_name": "Example Corp",
    "pbx_host": "pbx.example.com", "pbx_transport": "udp"
  }'
# → { ok, id: "tt_…", dns_records: [
#     { type: "CNAME", name: "sbc.example.com", value: "<tenant>.teams.sip.io", purpose: "traffic" },
#     { type: "CNAME", name: "_acme-challenge.sbc.example.com", value: "<tenant>.acme.sip.io", purpose: "acme-delegation" }
#   ] }

2. The customer adds the two CNAMEs, you verify. GET /v1/teams/{id}/dns checks both records live over DNS-over-HTTPS, no credentials needed on either side.

3. Provision. One call runs the whole state machine: issue the certificate over the delegation, place the tenant on an SBC node, serve the cert by SNI, write the traffic DNS, and mark it active.

curl -X POST https://api.sip.io/v1/teams/tt_.../provision -H 'x-api-key: sk_…'
# → { ok, provision_status: "active", node: "...", cname_target: "<tenant>.teams.sip.io" }

GET /v1/teams/{id}/cert returns a plain-language { state, expires_at, days_to_expiry } any time, so you can surface certificate health directly in your own portal, and certificates renew automatically well ahead of expiry. GET /v1/teams/{id}/cdrs returns the tenant’s call detail records, paginated.

The one remaining step is Microsoft’s

SIP.IO takes you all the way to a signaling-healthy SBC. From there, Microsoft owns the tenant-side voice policy: verify the SBC’s domain in the customer’s Microsoft 365 tenant, pair the gateway (New-CsOnlinePSTNGateway -Fqdn sbc.example.com -SipSignalingPort 5061), then assign a Teams Phone user an OnlineVoiceRoutingPolicy pointing at it.

Operational transparency

Beyond the authenticated /cert and /health endpoints for your own portal, each tenant gets a shareable public status page the customer switches on or off themselves, no API key required:

curl https://status.sip.io/st_9f3ab7c1...
# → { health: { state: "healthy", cert_served: true, microsoft: { hubs_up: 3 } } }

Each status link carries an unguessable token and is off by default. Flip it on and share the link; flip it off and the link stops resolving. The token only ever reveals that one tenant’s status, never an account key or another customer’s data. A disabled page or a wrong token returns 404; rotating the token revokes old links.

Architecture: three planes, cleanly separated

Control plane (the edge runtime + edge SQL database): tenant and node registry, the provisioning state machine, per-brand delegation logic, and writes the traffic DNS on placement.
Certificate service (ACME via a public CA): scoped provisioner tokens, DNS-01 issuance over the customer’s delegation CNAME, and a daily auto-renewal sweep. DNS credentials never leave this service.
Data plane (per-region SBC nodes): SNI-based TLS termination, SIP routing, SRTP↔RTP media, and OPTIONS keepalive in both directions to Microsoft’s PSTN hubs.

FAQ

What is Microsoft Teams Direct Routing? It connects Teams Phone System to the public telephone network, or your own PBX, via a certified SBC, without Microsoft Calling Plans. SIP.IO runs that SBC as a managed service instead of you buying and operating one.

Do I need to buy or manage an SBC? No. SIP.IO’s SBC fleet, per-tenant certificates, and DNS wiring are fully managed; you never touch an SBC.

Do I need to be a reseller or MSP to use this? No. Any account can provision one or more SBC tenants directly, for example one per region, subsidiary, or brand if you run multiple Microsoft 365 tenants yourself. White-labeling is available on top of that if you’re reselling to your own customers, but it isn’t required.

Can I white-label this? Yes. Each brand issues certificates into its own zone, so a reseller’s customers see only the reseller’s domain, and MSPs can nest this further under their own brand.

Pricing

Billed per tenant plus per channel (concurrent call capacity), covering managed SBC hosting, certificate lifecycle, and DNS automation. If SIP.IO also terminates the PSTN leg, minutes bill at the standard voice rates; a pure SBC hop to your own PBX or trunk carries no extra per-minute charge. See Pricing for current rates.

Talk to us · Platform overview · Pricing