# numbers.online — dSIPRouter integration (Kamailio redirect shim)

dSIPRouter is a management UI on top of **Kamailio**, so the numbers.online SBC
integration is the Kamailio redirect-server recipe applied to dSIPRouter's managed
configuration. There is no separate code path — dSIPRouter's value here is the UI,
key management, and per-tenant attribution.

## Apply the recipe

1. Take the Kamailio config from
   [`/integrations/kamailio/numbers_online_sbc.cfg`](/integrations/kamailio/numbers_online_sbc.cfg)
   and add it to your dSIPRouter-managed `kamailio.cfg` includes (the modules it loads —
   `http_async_client`, `jansson`, `tm`, `sl` — ship with Kamailio).
2. Provide your API key through a Kamailio `#!define`/AVP loaded from the environment —
   **never** a hardcoded literal in a committed config. Use a key with the
   `sbc_redirect` use case.
3. Reload Kamailio from the dSIPRouter UI (or `kamcmd cfg.reload`).
4. Call the `NUMBERS_ONLINE_CHECK` route early on inbound INVITE in your endpoint-group
   routing. It maps the decision to `603` (decline) / `302` (divert to your screening
   Contact) / `503`–`404` (route-advance), and **fails open** on any timeout or error.

## Multi-tenant deployments

Mint a per-tenant **sub-key** through the numbers.online MSP control plane and set it in
that tenant's configuration, so usage and billing roll up per customer.

## Packaged add-on (distribution note)

A productized dSIPRouter add-on (license-key activation + a UI toggle, following the
precedent of the dOpenSource TransNexus ClearIP module) is a **distribution** step that
requires a partner listing arrangement with dOpenSource — it is **not** required to use
this recipe today. The recipe above works on any Kamailio-based dSIPRouter install.

## Liability

The decision is a low-confidence **supplementary** signal. Your routing rules keep every
decision; a `603` block only ever follows a deterministic or government/licensed-
authoritative fact, never the spam score alone.