Yeti-Switch

Yeti‑Switch is a self‑hosted, open‑source softswitch that decouples SIP routing logic from the underlying Session Border Controller (SBC) engine. Built atop SEMS – a proven SBC written in C++ – Yeti replaces the native routing layer with a PostgreSQL‑backed, pluggable management plane. This separation enables developers to swap business rules, add features, or integrate with external systems without recompiling the core SBC. The project ships as a set of binaries (sems and yeti‑sems) plus a lightweight Ruby on Rails web interface for configuration, all of which communicate over well‑defined database tables and PL/pgSQL stored procedures.

Technical Stack

• Core SBC: Modified SEMS (C++), responsible for media handling, SIP signaling, and NAT traversal.
• Management Layer: PostgreSQL 12+ storing routing tables, user profiles, and feature flags. Business logic resides in PL/pgSQL procedures that the SBC calls via a lightweight RPC over the database.
• Web UI & API: Ruby on Rails 6+ application providing CRUD for routing tables, user management, and monitoring dashboards. The Rails layer exposes a RESTful API that developers can consume for automation or integration with third‑party services.
• Deployment: Docker images are available for all components, allowing quick spin‑up in Kubernetes or any container runtime. The Rails app can also run as a standalone process on Linux hosts.

Core Capabilities

• Dynamic Routing: Call routing decisions are made in the database; changing a route only requires an UPDATE statement, no SBC restart.
• Feature Flags: Enable or disable SIP features (e.g., video, RTP‑mux) per call via stored procedures.
• Call Accounting: Built‑in CDR generation that writes directly to PostgreSQL tables, ready for reporting or billing integration.
• REST API: Exposes endpoints for creating users, provisioning extensions, and querying call status.
• Webhooks: Optional webhook hooks trigger on events such as call start/end, allowing real‑time integration with external services (e.g., chatops, monitoring).

Deployment & Infrastructure

Yeti‑Switch is designed for self‑hosting on commodity Linux servers. A typical stack consists of:

1. SBC Container – runs the modified SEMS binary, connects to PostgreSQL via a Unix socket or TCP.
2. PostgreSQL Container – stores all routing logic; can be scaled vertically (larger RAM) or horizontally using streaming replication for read replicas.
3. Rails Container – hosts the web UI and API; can be load‑balanced behind a reverse proxy (NGINX/Traefik).

Because the routing layer is purely database‑driven, horizontal scaling of the Rails API or PostgreSQL read replicas can be added without touching the SBC. For high‑availability, each component can run in a Kubernetes pod with persistent volumes.

Integration & Extensibility

• Plugin System: Developers can write custom PL/pgSQL modules or even external services that hook into the database.
• API Extensions: The Rails API can be extended with new endpoints; authentication is handled via Devise or OAuth2.
• Webhooks & Callbacks: Events such as call_created, call_ended are exposed to external systems via configurable webhook URLs.
• Custom Dialplans: Dialplan logic can be expressed in SQL, allowing complex patterns (regex, country codes) without recompiling the SBC.

Developer Experience

• Configuration: Most settings are database entries; no need to edit C++ config files.
• Documentation: The project includes a comprehensive README, API reference, and database schema diagrams.
• Community: An active GitHub community provides issue tracking, pull requests, and a mailing list for support.
• Licensing: Released under the MIT license, giving developers full freedom to modify and redistribute.

Use Cases

Advantages

• Performance: Core SBC remains lightweight C++ code; only database lookups add latency, which is negligible for most use cases.
• Flexibility: Business logic lives in PostgreSQL, so developers can change routing rules without downtime.
• Licensing: MIT license removes vendor lock‑in, encouraging custom extensions.
• Scalability: Database replication and container orchestration allow horizontal scaling of the API layer without touching the SBC.
• Extensibility: Built‑in REST API, webhooks, and PL/pgSQL hooks provide multiple integration paths for third‑party services.

In summary, Yeti‑Switch offers a modern, database‑centric approach to softswitch management that empowers developers to iterate quickly, scale horizontally, and integrate seamlessly with existing infrastructure—all while leveraging the proven reliability of SEMS.