.jpg)
Mit sipgate flow verbinden unsere Kund:innen ihre Voicebots mit unserer Telefonie, inklusive TTS und STT. Den Audiostrom handlen komplett wir. Aber immer häufiger hörten wir eine andere Anfrage: von AI-Startups, Entwickler:innen und Unternehmen, die ihre Voice-AI auf ElevenLabs, Livekit oder einer eigenen Plattform bereits gebaut haben und z.B. Audio-zu-Audio verwenden. Sie brauchten kein STT und kein TTS. Sie brauchten einen zuverlässigen Telefonanschluss aus und in Europa, der ihnen den rohen Audiostrom liefert.
Das Problem: Bisher war Twilio dafür so fast wie der Industriestandard. Und genau da wird es interessant.
Twilio scheint DIE Lösung zu sein. Es gibt aber ein Aber.
Twilio hat zweifellos eine mächtige Plattform. Ihre Media-Streams haben sich als De-facto-Standard für Echtzeit-Audio im Voice-AI-Bereich etabliert. Viele Plattformen und Frameworks sprechen diese Sprache nativ. Wer schnell loslegen will, nimmt Twilio. Auch die Anbindung von ElevenLabs und Vapi an die Telefonie scheint mit Twilio ein Klacks zu sein.
Warum auch nicht? Hm…
Jurisdiktion: EU-Server lösen das Problem nicht. Ja, Twilio hat ein Rechenzentrum in Irland und eine EU-Tochtergesellschaft. Aber Twilio Inc. bleibt ein US-Unternehmen – und damit greift der CLOUD Act. Das Gesetz erlaubt US-Behörden, Daten von amerikanischen Unternehmen anzufordern, unabhängig davon, wo sie gespeichert sind. Dublin oder Frankfurt, spielt keine Rolle. Dieser Jurisdiktionskonflikt mit der DSGVO lässt sich vertraglich nicht auflösen.
Architektur: Audio macht einen Umweg. Bei Twilio Media Streams läuft der Audiostrom immer über Twilios Infrastruktur als Media-Relay in der Mitte. Das erzeugt zusätzliche Latenz – und bei Voice AI zählt jede Millisekunde. Mit einem direkten SIP-Trunk geht der Audiostrom ohne Zwischenstation dorthin, wo er gebraucht wird - in der Applikation.
Audioqualität: Festgenagelt auf 8 kHz µ-law. Moderne Voice-AI-Plattformen arbeiten mit 16 oder 24 kHz PCM. Twilio Media Streams liefern aber nur 8 kHz µ-law. Das bedeutet: doppeltes Transcoding auf jedem Call, Artefakte, schlechtere ASR-Erkennungsqualität. Wer schon mal Twilio mit OpenAI Realtime verbunden hat, kennt die Debugging-Sessions. Über SIP verhandeln die Plattformen den Codec direkt – ohne Flaschenhals.
Default ist US. Sämtliche Twilio-Ressourcen landen standardmäßig in der US1-Region und in der Praxis wird es oft übersehen. EU-Routing erfordert explizite Konfiguration mit regionalen API-Keys und separaten TwiML-Apps. Machbar – aber nicht die Standardeinstellung.
Unsere Antwort: Zwei Open-Source-Bridges
Statt selbst eine proprietäre Lösung zu bauen, haben wir zwei schlanke Open-Source-Projekte veröffentlicht, die auf sipgate Trunking aufsetzen:
sip-bridge – Ein minimaler Asterisk-Container, der eingehende Anrufe über einen sipgate Trunk entgegennimmt und per SIP direkt an AI-Voice-Plattformen weiterleitet. Konfiguration über eine .env-Datei, Start mit einem einzigen Docker-Befehl. Ressourcenverbrauch: 30–50 MB RAM.
SIP Stream Bridge – Für alle, die bereits ein Backend gebaut haben, das die Twilio-Media-Streams-API spricht. Die Bridge “übersetzt” zwischen sipgate SIP-Telefonie und dem Twilio-Protokoll. Das Backend merkt keinen Unterschied. Es denkt, es redet mit Twilio. Nur dass die Telefonie jetzt über sipgate läuft. Verfügbar als Go-Version (~10 MB, produktionsreif), als Node.js-Referenzimplementierung und beides direkt im fertigen Docker-Container, um sofort loszulegen.
Beide Projekte sind MIT-lizenziert, komplett quelloffen und laufen auf dem kleinsten Cloud-Server.
Warum wir das so machen
Wir glauben, dass die Zukunft von Voice AI nicht (nur) darin liegt, alles selbst zu kontrollieren. Sondern darin, die beste Infrastruktur bereitzustellen und Entwickler:innen die Freiheit zu geben, darauf aufzubauen. sipgate Trunking liefert die Telefonie. Die Bridges liefern die Verbindung. Was dazwischen passiert, ist euer Part.
Und ja: Wir glauben auch, dass Europa technisch starke Lösungen hat und dass es sich lohnt, Abhängigkeiten von US-Infrastruktur dort zu reduzieren, wo es Alternativen gibt. Nicht aus Prinzip, sondern weil es in diesem Fall die kürzeren Latenzen, die bessere Audioqualität und die klarere Rechtslage liefert.
Klingt gut? Holt euch einen sipgate Trunk, klont das passende Bridge-Repo, und legt los. Wir freuen uns auf euer Feedback – und auf die Dinge, die ihr damit baut.
Und falls ihr euch fragt, ob es nicht doch eine attraktive Alternative sein könnte, STT und TTS direkt mit zu beziehen, ohne zusätzliche API Keys, dafür aber mit extrem geringen Latenzen, dann ist vielleicht doch sipgate flow die Antwort!
.jpg)
.jpg)
