Ein Trunk ist die Grenze, an der der Carrier entscheidet, welche Anrufe Ihre Infrastruktur senden und empfangen darf. Wenn Sie eine PBX haben, die Telefonanlage, die Ihre Anrufe routet, einen Session Border Controller, eine Contact-Center-Plattform oder einen anderen SIP-Client, dann ist der Trunk der Weg, über den seine Anrufe die Außenwelt erreichen und umgekehrt. Ein Session Border Controller ist das Gerät, das den Rand eines Sprachnetzes absichert.
Die erste Frage ist meist, ob Sie überhaupt einen brauchen, und die Antwort ist ja. Was variiert, ist das, was Sie dahinter betreiben.
Brauche ich wirklich einen Trunk?
Ja. Was sich zwischen Setups unterscheidet, ist der Client auf Ihrer Seite, nicht ob es einen Trunk gibt.
Jeder Anruf zum oder vom Telefonnetz läuft über einen, weil der Trunk die Stelle ist, an der die Plattform entscheidet, ob sie den Anruf überhaupt annimmt. Zwei Varianten sind üblich:
- Sie haben eine Telefonanlage. Eine PBX, ein Softswitch oder eine Contact-Center-Plattform, die bereits Anrufe verarbeitet und eine Route ins öffentliche Netz braucht. Sie verbindet sich als Peer, meist von einer festen Adresse aus, und ihr eigener Wählplan, die Regeln, die ihre Anrufe routen, übernimmt die Anrufsteuerung.
- Sie haben Anwendungscode. Ihre Software soll Anrufe tätigen oder empfangen, ohne dass Sie Telefonie-Infrastruktur betreiben. Sie brauchen trotzdem einen Trunk, und das, was mit ihm kommuniziert, kann klein sein: ein Softphone, ein Browser, die CLI oder eine Voice-Agent-Runtime. Es authentifiziert sich mit einem kurzlebigen Session-Credential, einem temporären Benutzernamen und Passwort für einen SIP-Client, statt von Infrastruktur an einer bekannten Adresse.
Der Unterschied betrifft den Ort der Anrufsteuerung, nicht die Größenordnung, und keine der beiden Varianten umgeht den Trunk. Ein leichter Client erspart Ihnen den Betrieb einer Telefonanlage, nicht die Verbindung selbst. Das eigene Tooling von Bird verdeutlicht das gleich doppelt: Das Telefon im Dashboard und der Testanruf der CLI sind beides SIP-Clients, die echte Anrufe über einen Ihrer Trunks tätigen.
Der Trunk ist auch keine Alternative zur API, weil kein Endpunkt einen Anruf an ein von Ihnen gewähltes Ziel absetzt. Was ist ein Voice-API erklärt, wie sich die konfigurierende und die signalisierende Hälfte die Arbeit teilen.
Was macht ein Trunk eigentlich?
Er gibt Ihrer Infrastruktur eine Adresse, an die sie Anrufe senden kann, und entscheidet, welche Anrufe er annimmt.
Bird weist jedem Trunk eine feste SIP-Domain zu, die Sie in Ihrer Telefonanlage eintragen, damit Anrufe dem Trunk zugeordnet werden können. Ihre Infrastruktur sendet an diese Domain über einen von drei Transporten: UDP oder TCP auf 5060 oder TLS auf 5061, wenn Sie die Signalisierung bei der Übertragung verschlüsseln möchten.
Ein neuer Trunk weist jeden Anruf ab. Beide Richtungen sind deaktiviert, und kein Absender ist autorisiert. Das ist ein bewusster Standard, kein unvollständiges Setup. Ein Trunk, der Anrufe sofort nach seiner Erstellung akzeptiert hätte, wäre eine offene Einladung, und Toll Fraud macht das schnell teuer.
Warum werden Outbound und Inbound getrennt konfiguriert?
Weil es unterschiedliche Probleme mit unterschiedlichen Fehlermodi sind und ein Trunk jede Richtung eigenständig führt.
Outbound bedeutet, dass Ihre Telefonanlage Anrufe über Bird tätigt. Bis Sie es aktivieren, lehnt der Trunk jeden ausgehenden Versuch unabhängig von den Credentials ab. Ein korrekt authentifizierter Anruf schlägt also trotzdem fehl, wenn die Richtung deaktiviert ist.
Inbound bedeutet, dass Bird Anrufe an Ihre Telefonanlage für die Nummern ausliefert, die auf den Trunk zeigen. Das Aktivieren allein reicht nicht: Ein Trunk mit aktiviertem Inbound und ohne Delivery-Gateway lehnt jeden eingehenden Anruf an seine Nummern ab. Das Zuweisen einer Nummer zum Trunk erfolgt an der Nummer, nicht am Trunk, und das ist die andere Hälfte, die oft übersehen wird.
Das Deaktivieren von Inbound setzt jede Nummer, die auf diesen Trunk zeigt, auf Reject zurück, und das erneute Aktivieren stellt sie nicht wieder her. Das Löschen des Trunks bewirkt dasselbe. Der Vorgang ist also nicht symmetrisch umkehrbar: Wenn Sie Inbound zum Testen deaktivieren, planen Sie ein, jede Nummer danach erneut zuzuweisen, und prüfen Sie die Nummern, statt anzunehmen, dass der Schalter sie wiederhergestellt hat.
Wie entscheidet ein Trunk, wer ihm Anrufe senden darf?
Eine IP-Allowlist, API-Key-Authentifizierung und Session-Credentials entscheiden das. Sie lassen sich kombinieren, und jede wird aktiv, sobald sie einen Eintrag hat.
Eine IP-Allowlist. Fügen Sie die öffentlichen Adressen hinzu, von denen Ihre Infrastruktur an SIP sendet. Die Filterung beginnt, sobald die Liste einen Eintrag hat, und ab dann dürfen nur gelistete Bereiche Anrufe senden. Bei Infrastruktur hinter NAT ist das die öffentliche Adresse des Routers, nicht die private der Telefonanlage. Anrufe von nicht gelisteten Adressen werden auf der SIP-Schicht abgelehnt und erreichen meist nie das Anrufprotokoll. Ein leeres Protokoll ist daher ein Symptom dafür, nicht der Beweis, dass nichts versucht wurde.
API-Key-Authentifizierung. Bird fordert den Anruf heraus, und Ihr System antwortet mit einem Hash des Passworts statt mit dem Passwort selbst. Der Hash wird gegen einen Bird-API-Key geprüft, der Voice-Zugriff auf Write-Level hat. In Ihrer PBX ist der Benutzername immer bird und das Passwort ist das Secret des Keys. Wie die IP-Liste wird er exklusiv, sobald ein Key erlaubt ist.
Daraus folgen zwei operative Details. Wenn Sie die Voice-Berechtigung von einem Key entfernen, stoppt dessen Authentifizierung sofort. Der Key bleibt in der Allowlist des Trunks, markiert, damit die Liste nie als funktionierend erscheint, wenn sie es nicht ist. Das Wiederherstellen der Berechtigung aktiviert ihn, ohne dass etwas geändert werden muss. Das Widerrufen oder Löschen des Keys wirkt sofort auf jeden Trunk, der ihn erlaubt hat, und ist dauerhaft. Rotieren Sie, indem Sie den neuen Key zuerst zum Trunk hinzufügen, dann Ihre Infrastruktur umstellen und den alten Key zuletzt widerrufen.
Session-Credentials. Ein kurzlebiger SIP-Benutzername und ein Passwort, die dieselbe Challenge beantworten, ohne ein langlebiges Secret preiszugeben. Sie sind auf einem neuen Trunk deaktiviert und gehören zum Workspace, nicht zu einem einzelnen Trunk. Das Passwort wird nur bei der Erstellung zurückgegeben.
Das Aktivieren von Session-Credentials ändert nichts daran, wie Infrastruktur auf der Allowlist sich verbindet. Ein Anruf von einer gelisteten Adresse auf einem Trunk ohne erlaubte API-Keys wird weiterhin ohne Passwort-Challenge zugelassen. Wenn das Credential als Zugangstor gedacht war, ist die IP-Liste still und heimlich weiterhin das Zugangstor.
Warum schlägt die Authentifizierung meines Browsers oder Softphones fehl?
Fast immer der Digest-Algorithmus. Er ist die einzige Einstellung, die so fehlschlägt, dass es wie ein Credential-Problem aussieht.
Standardmäßig bietet Bird zuerst SHA-256 und dann MD5 an, und Ihre Infrastruktur antwortet mit dem ersten, den sie unterstützt. Ein Trunk akzeptiert nur die Algorithmen, die er anbietet. Wenn Sie das Angebot einschränken, schränken Sie ein, was sich verbinden kann.
Die Falle sind Browser: Ein Browser antwortet mit MD5 und sonst nichts. Ein Trunk, der nur SHA-256 anbietet, lehnt jeden Browseranruf ab, einschließlich des eigenen Telefons im Dashboard. Behalten Sie MD5 also im Angebot auf jedem Trunk, von dem Sie aus einem Browser anrufen möchten, und greifen Sie nur dann zu MD5-only, wenn eine PBX eine Challenge, die mit SHA-256 beginnt, falsch verarbeitet. API-Keys funktionieren mit beiden Algorithmen und müssen nie neu ausgestellt werden, wenn Sie das Angebot ändern.
Was richte ich also ein?
- Einen Trunk, unabhängig von Ihrer Variante. Jeder Anruf läuft über einen, dieser Schritt ist also nicht optional.
- Einen Peer, wenn Sie eine Telefonanlage betreiben. Verbinden Sie die PBX oder Contact-Center-Plattform von einer festen Adresse und lassen Sie deren Wählplan die Anrufe steuern.
- Einen leichten Client, wenn Sie Anwendungscode haben. Ein Softphone, ein Browser, die CLI oder eine Agent-Runtime, die sich mit einem kurzlebigen Session-Credential statt einer bekannten Adresse authentifiziert.
- Eine Absenderregel, egal welche Variante Sie gewählt haben. Eine IP-Allowlist, ein erlaubter API-Key oder ein Session-Credential, wobei jede exklusiv wird, sobald sie einen Eintrag hat.
- MD5 im Digest-Angebot belassen auf jedem Trunk, von dem Sie aus einem Browser anrufen möchten.
SIP-Trunks behandelt jede Einstellung und wo Sie sie finden. SIP-Clients behandelt das Verbinden eines einzelnen Clients statt einer Telefonanlage, und Voice-Fehlerbehebung hilft bei Anrufen, die nicht ankommen.
Kurz gesagt
Jeder Weg zum Telefonnetz führt über einen Trunk.
Der Unterschied liegt im Client auf Ihrer Seite: eine Telefonanlage, die als Peer verbunden ist, oder ein leichterer SIP-Client wie ein Browser oder die CLI mit einem kurzlebigen Credential.
Ein neuer Trunk lehnt alles ab.
Beide Richtungen sind deaktiviert, und es gibt keinen autorisierten Absender, bis Sie einen hinzufügen. Das ist beabsichtigt, kein Einrichtungsschritt, den Sie überspringen können.
Jede Richtung wird einzeln aktiviert, und Inbound braucht ein Gateway.
Ein Trunk mit aktiviertem Inbound, aber ohne Delivery-Gateway lehnt jeden eingehenden Anruf an seine Nummern ab.
Das Deaktivieren von Inbound lässt sich nicht sauber rückgängig machen.
Jede Nummer, die auf den Trunk zeigt, fällt auf Reject zurück, und das erneute Aktivieren von Inbound stellt sie nicht wieder her. Verweisen Sie jede Nummer selbst erneut.