Skip to main content
Store registrations in Redis instead of process memory, so several Location Service instances share one view of where every endpoint is.

​
When you need Redis

The Location Service supports two cache providers: memory and redis. Memory is fine for a single instance. Switch to Redis when any of these apply:
  • You run more than one Location Service instance. With memory, each instance only knows the registrations it received, so lookups on another instance miss them.
  • You balance Peers with least-sessions. The algorithm picks the Peer contact with the fewest active sessions, and that count must be shared across instances. See Load balancing.
  • You want registrations to survive a Location Service restart. With memory, a restart clears the location table until clients register again.

​
Prerequisites

  • A Redis server reachable from the Location Service, or permission to run one next to it.
  • A deployment where the Location Service runs as its own service. The all-in-one fonoster/routr-one image always uses the memory provider, so use the split images on Docker or the Helm chart on Kubernetes.

​
Switch the cache provider

1

Add Redis to your Compose file

Add a Redis service next to the location service. The following snippet shows only the services that change.
compose.yaml
2

Point the Location Service at Redis

Set cache.provider to redis and pass the connection in cache.parameters as comma-separated key=value pairs.
config/location.yaml
The accepted keys are host, port, username, password, and secure (set secure=true to connect over TLS). Always set host and port. Any other key makes the service fail to start.
3

Restart the services

Recreate the Location Service so it loads the new configuration.

​
Verify

Check the Location Service logs for the provider it loaded.
The logs include using redis as cache provider. On Kubernetes, run kubectl logs on a Location pod instead.
Register a softphone, then list the keys in Redis. Each key starts with the endpoint’s address of record.

​
Pitfalls

  • Redis connection errors at startup. The service logs redis client error and lookups fail. Check that host and port resolve from inside the Location Service container.
  • Registrations disappear. Each entry expires with the registration’s expires value. Clients must refresh their registration before it expires.
  • Old registrations after switching. Registrations held in memory are not migrated. Clients appear in Redis after their next REGISTER.

Location Service reference

Configuration spec and gRPC API.

Load balancing

Round-robin, least-sessions, and session affinity.

Load balancing Asterisk

Put several Asterisk servers behind one Peer.

Deploy on Kubernetes

Install the chart with Redis included.