Routr splits SIP into separate containers and leaves STIR/SHAKEN and its web app unchecked

What Routr is: a SIP edge, not a media server

Routr describes itself as a lightweight SIP proxy, location server and registrar, providing SIP infrastructure for telephony carriers, service providers and integrators. The repository description calls it a programmable SIP server.

The scope matters. Routr sits in front of media servers rather than replacing them. The feature list names load balancing strategies against media servers like Asterisk and FreeSWITCH, and the repository topics include asterisk, freeswitch, kamailio and opensips alongside webrtc and twilio.

So the division of labour is: Routr terminates SIP signalling, decides where a call should go, keeps the registration state, and balances across your media servers. It does not process the audio itself.

The core feature checklist is worth reading as a boundary rather than a sales list. Common SIP functions, proxy, registrar and location service. Programmable routing with configurable strategies named Intra-Domain, Domain Ingress, Domain Egress and Peer Egress. Multi-tenant and multi-domain with a domain level access control list. Session affinity. Transports TCP, UDP, TLS, WS and WSS. Location storage in memory or in Redis, with JSON, YAML or Postgres as the data source. Server management over a gRPC API, a NodeSDK and a command line tool. RTPEngine middleware. A Helm chart. Endpoint authentication with JWT for web phones.

Two entries are unchecked: region-based routing, and support for STIR/SHAKEN.

The single container quickstart, and what it does not expose

The shortest path is one container. The README gives a Compose file that runs the `fonoster/routr-one:latest` image:

version: "3"

services:
  routr:
    image: fonoster/routr-one:latest
    environment:
      EXTERNAL_ADDRS: ${DOCKER_HOST_ADDRESS}
    ports:
      - 51908:51908
      - 5060:5060/udp
    volumes:
      - shared:/var/lib/postgresql/data

volumes:
  shared:

`EXTERNAL_ADDRS` is the one value you must set, and the README is explicit that you replace it with your own IP address:

DOCKER_HOST_ADDRESS=192.168.1.3 docker-compose up

There is also a plain `docker run` form mapping the same two ports and passing `-e EXTERNAL_ADDRS=192.168.1.3`. After a few seconds you check with `docker ps -a --format 'table {{.ID}}\t{{.Image}}\t{{.Status}}'` and look for a container with status Up.

Note what that quickstart maps. Port 5060 is published over UDP only, plus 51908 which is the management port. If you need SIP over TCP or TLS, the single-container quickstart does not give it to you.

The Dockerfile explains why the quickstart works at all. The `routr-one` image is a multi-stage build on alpine:3.23 that bundles the services together, starts an internal Postgres with `START_INTERNAL_DB=true`, and generates certificates at startup with `TLS_ON=false` by default. For anything beyond evaluation, that default is what you change.

compose.yaml shows the real architecture: seven services, not one

The development compose file in the repository root is more informative than the quickstart, because it separates everything.

Two EdgePort servers, `edgeport01` on ports 5060 through 5063 and `edgeport02` on 6060 through 6063, each with a config file mounted at /etc/routr/edgeport.yaml. A dispatcher, which the comment says takes care of routing traffic from the EdgePort servers, on 51901. A location service on 51902, commented as storing the location of all SIP endpoints in the network. A connect processor on 51904. A simple API server using the simpledata image on 51907. A requester on 51909, commented as taking gRPC requests and sending them to an EdgePort. And a registry on 51910, which sends registration requests on behalf of trunks.

Note that EdgePort01 publishes both 5060:5060 and 5060:5060/udp, so TCP and UDP are both available there. The single-container quickstart shows only the UDP mapping.

The split is not decoration. The dispatcher is the piece that makes the feature list's "no single point of failure" claim structural rather than aspirational: two EdgePorts front two independent roles, and the registry exists so that trunks do not have to register themselves on every server.

Each service also has its own start script in package.json, such as `start:dispatcher` with `CONFIG_PATH` pointing at config/dispatcher.yaml, and `start:registry` with config/registry.yaml. That is how you run one component in isolation while developing.

Programmable routing: processors, middleware and the gRPC surface

Programmability is the reason to consider Routr over an existing open source SIP server, and it is visible in three places.

The README has a section titled "Building custom processors and middleware", and the feature list calls out RTPEngine middleware as a built-in example. A processor is a unit of call handling you write, and middleware modifies a request on its way through. In practice this is what lets you apply a policy that is not expressible as a routing table.

The second surface is the gRPC API for server management. The requester service sits on 51909 and is described as taking gRPC requests and sending them to an EdgePort, while the API server on 51907 is the gRPC endpoint itself. The apiserver component has two implementations referenced in the development scripts, a simple one backed by JSON and YAML files and a `pgdata` one backed by Postgres through a Prisma schema.

The third is the NodeSDK and the CTL command line tool, which are the programmatic and human interfaces onto the same API.

What this means in practice is that adding functionality does not require forking the SIP core. You write a processor or middleware in TypeScript and the routing stays declarative. That is the substantive difference from a traditional SIP server configured entirely through config files, and it is the argument in the repository description.

Helm for Kubernetes, and what the chart covers

Kubernetes deployment goes through Helm. The README's sequence is a repo add, a namespace, and an install:

helm repo add routr https://routr.io/charts
helm repo update

kubectl create namespace routr

helm install my-release routr/routr-connect --namespace routr

Then you wait for the pods to start. The install line names the `routr-connect` chart specifically, which corresponds to the connect processor in the compose file, and the README notes you can use Minikube or Docker Desktop for a local cluster.

Two deployment facts are worth flagging. First, the Helm repository is served from routr.io/charts rather than from the GitHub repository, so the chart version you install is not pinned by the commit you read in the repository. Second, the compose services mostly use `expose` rather than `ports`, meaning they are reachable inside the cluster but not published outside it, while EdgePort publishes its SIP ports. That is the right default for internal services and it means the SIP surface of a Kubernetes install is the EdgePort, not the rest.

The feature list includes a Helm chart for Kubernetes deployments and a claim of no single point of failure. Whether a given chart topology is actually highly available depends on the replica counts you configure, which the README does not spell out.

JWT endpoint auth for web phones, and the attestation gap

For anyone connecting a browser softphone, the relevant feature is endpoint authentication with JWT.

Two features are marked unfinished in the checklist. STIR/SHAKEN support is one. That is the attestation framework for caller identity in SIP, and its absence is a real constraint if you are deploying in a jurisdiction that requires it or if your carriers are beginning to filter on it. The other is a web application, meaning the management surface is the gRPC API, the CTL tool and the NodeSDK rather than a browser interface.

The pairing of those two gaps is worth noticing. JWT auth for endpoints is the capability that makes browser-based calling feasible, and the web application is the capability that would make it usable by people who are not writing a NodeSDK client. Right now the project supports the technical path and not the ergonomic one.

Region-based routing is also unchecked, which matters if you need geographic failover between media server pools. Load balancing strategies and session affinity are listed as complete, so per-domain and per-call balancing is available; what is missing is choosing the pool by geography.

Maintenance, licensing and the Java in the build

The repository is not archived. The last push was on 2026-09-08, and v2.15.1 was tagged on 2026-09-07, a day earlier. The other listed releases are v2.15.0 from 2026-06-29 and v2.13.21 from 2025-12-24. That is a project shipping patch releases within the 2.13 and 2.15 lines.

The primary language is TypeScript, and the package.json is an npm workspace root named `root` with `mods/*` as workspaces. But the Dockerfile shows something different about the build: it installs `openjdk17-jdk`, sets `JAVA_HOME`, runs a custom JRE script, downloads a JRE into `/service/jre`, and configures `LOG4J2` with a log4j2.yaml. There is also a `build.gradle`, `settings.gradle` and `gradlew` at the repository root, plus `.mocharc.json`.

So a TypeScript codebase with a Gradle build and a Java runtime in the container. Anyone assessing the operational footprint should confirm where the Java dependency actually sits before sizing a deployment, since the README does not explain it.

The licence is MIT, with the LICENSE file at the repository root. That is a licensing note and not legal advice. The Dockerfile also embeds a third-party binary, `heplify` v1.67.1 from the sipcapture project, fetched at build time, which is a separate licence you should account for. The same applies to RTPEngine and Alpine base packages.

Editorial conclusion

Adopt Routr if you need a SIP edge that you can deploy as separate containers, script through a gRPC API and control with custom processors, and your calls terminate on Asterisk or FreeSWITCH. Do not adopt it if you need STIR/SHAKEN attestation or a web management interface, since both are listed as unfinished. Verify first that the container image you pull exposes the SIP ports you need on your network, because the single-container quickstart maps 5060 over UDP only while the multi-service compose file maps a wider set including TCP.

Frequently asked questions

Official sources

1. fonoster/routr on GitHub
2. License: MIT
3. Project website
4. README
5. Releases