Skip to main content
Routr is not one server process. It’s a set of loosely coupled services that talk to each other over gRPC. Each service has one job, and you can scale, restart, or replace it without touching the others. Routr architecture: SIP clients connect to EdgePorts, which send messages to the Message Dispatcher; the Dispatcher passes them through Middlewares to Processors such as Connect, which use the Location Service, the API Server backed by YAML or PostgreSQL, and Redis; the RTPRelay middleware drives RTPEngine Routr architecture: SIP clients connect to EdgePorts, which send messages to the Message Dispatcher; the Dispatcher passes them through Middlewares to Processors such as Connect, which use the Location Service, the API Server backed by YAML or PostgreSQL, and Redis; the RTPRelay middleware drives RTPEngine

​
Why services instead of a monolith

A traditional SIP server puts the network stack, the routing logic, and the data in the same process, and you program it with a configuration script. Routr separates them:
  • Only the edge speaks SIP. Everything behind it receives a protobuf message and returns one.
  • Routing logic lives in a Processor, so you can write your own in any language with gRPC support.
  • Each service scales on its own. If routing needs more CPU, you add Processor replicas, not more SIP edges.
The trade-off is more moving parts. For a single host, the fonoster/routr-one image runs all of them in one container so you don’t have to wire them together. See Deployment topologies.

​
Components

​
Core

These services make up the core of Routr, described in the Core specification.

​
Connect mode and supporting services

Routr handles signaling only. Media flows directly between endpoints, or through RTPEngine when you use RTPRelay. To run IVRs, conferences, or voicemail, put Routr in front of a media server such as Asterisk or FreeSWITCH.

​
Stateful and stateless services

The EdgePort is the only stateful service. It keeps SIP transactions and the connections that clients opened to it, because SIP requires that a response goes back on the same transaction and, for TCP, TLS, and WebSocket, over the same connection. Losing an EdgePort loses the transactions and connections it held. Clients reconnect and re-register. The Message Dispatcher, Processors, and Middlewares are stateless. Every message they receive carries everything needed to process it: the SIP message plus metadata such as the EdgePort reference, its listening points, its external addresses, and its local networks. Any replica can handle any message, so you scale them horizontally behind a regular Kubernetes service. Data lives in two places outside the request path:
  • Registrations live in the Location Service. With the memory provider, they exist only inside one Location instance. Use redis to share them across several instances.
  • Resources live behind the API Server, in YAML files or PostgreSQL.

​
Specifications

Routr’s behavior is written down in two draft specifications. You don’t need them to use Routr, but read them before you build your own Processor or replace a component.

Message flow

Follow one request from the EdgePort to the Processor and back.

EdgePort cooperation

Learn how several EdgePorts route calls without a SIP load balancer.

Connect mode

See the resources the built-in Processor works with.

Deployment topologies

Choose between the all-in-one image and the Helm chart.