Zum Hauptinhalt springen
Wenn deine Organisation eine eigene PBX oder Contact-Center-Plattform betreibt, kannst du sie genauso verbinden wie jeden anderen SIP-Trunk – keine Nummernportierung nötig. Die gemeinsamen Grundlagen (Plattform-SIP-FQDN, exakte DID und Inbound-Authentifizierung) findest du in den SIP-Anbieter-Anleitungen; diese Seite behandelt die Besonderheiten von sieben PBX- und Contact-Center-Plattformen, einschließlich einiger Dinge, die kaputt wirken, aber normal sind.
Der Verbindungstyp Generic SIP Trunk (IP Based) von 3CX ist nur bei StartUP PRO und bei selbstverwalteten/Dedicated-Instanzen verfügbar – die Einstiegsstufe StartUP bietet ihn nicht.
  1. Erstelle in 3CX einen Generic SIP Trunk mit IP-basierter Authentifizierung, nicht mit SIP-Registrierung.
  2. Richte ihn auf den Plattform-SIP-FQDN aus, stelle den Trunk-Transport auf TCP (UDP fragmentiert große INVITEs) und beschränke die Codecs auf PCMA/PCMU mit RFC2833-DTMF – deaktiviere Opus und G.722.
  3. Setze From: Display-Name und Remote-Party-ID des Trunks auf OriginatorCallerID, damit der Assistent die echte Anrufernummer sieht, nicht die eigene Systemnummer von 3CX.
  4. Konfiguriere Inbound in zwei Teilen: eine Outbound-Regel mit einem eigenen Präfix (zum Beispiel 999), die zum Trunk geroutet wird, und eine Inbound-Regel, die 999<number> über genau diese Outbound-Regel zurückwählt.
  5. Weise die DID auf Plattformseite zu und teste.

3CX-Anrufrouting — schematische Darstellung

Diese Beispiele zeigen die relevanten Einstellungen; das Layout kann in der aktuellen Konsole deines Anbieters abweichen.
3CX-Trunk-Tab Options mit Transport Protocol auf TCP und deaktiviertem SRTP Mode

Konfigurationsbeispiel — Stelle das Transportprotokoll des Trunks auf TCP

3CX-Trunk Caller-ID-Optionen mit From: Display Name und Remote Party ID – Calling Party: Display Name, beide auf OriginatorCallerID gesetzt

Konfigurationsbeispiel — Reiche die echte Anrufer-ID mit OriginatorCallerID durch

Das Diagramm zeigt die Routing-Beziehung, nicht die 3CX-Einstellungsseite. Menünamen hängen von deiner 3CX-Version ab. Die 3CX-Referenz für Anrufer-ID-Felder erläutert OriginatorCallerID und die konfigurierbaren SIP-Felder.
Die Outbound-Regel allein bewirkt nichts. Erst das Zusammenspiel aus Schritt 4 – eine Outbound-Regel plus eine passende Inbound-Regel, die darüber wählt – routet einen eingehenden Anruf tatsächlich zum Assistenten. Wird das übersprungen, ist das die häufigste Ursache für „Trunk konfiguriert, aber es kommen nie Anrufe an”.
Konfiguriere in beide Richtungen einen statischen, nicht registrierenden Trunk – Asterisk sendet der Plattform nie ein SIP REGISTER, und die Plattform erwartet auch keins.

FreePBX (GUI)

Füge einen generischen SIP-Trunk hinzu, der auf den Plattform-SIP-FQDN zeigt, und deaktiviere die Registrierung. Beschränke die Codecs auf PCMA/PCMU. Sitzt Asterisk hinter NAT, setze die externen Medien- und Signalisierungsadressen sowie den lokalen Netzbereich, damit RTP korrekt aushandelt, und leite den RTP-Portbereich an der Firewall weiter.

Rohkonfiguration (pjsip.conf)

Das Beispiel nutzt den Transport, den deine Asterisk-Installation bereits definiert. Benennst du deine Transporte explizit, ergänze eine passende transport=-Zeile am Endpoint – die Plattform-SIP-URI kündigt standardmäßig TCP an.Verbinden sich Anrufe, brechen aber exakt nach 30 Sekunden ab, fehlt dem Endpoint ein Re-INVITE über NAT hinweg. direct_media=no und rewrite_contact=yes (bereits im obigen Beispiel enthalten) beheben das.
Verbinde Starface über eine host-/IP-basierte SIP-Leitung, nicht über SIP REGISTER – die Leitung zeigt in Starfaces Statusansicht danach not registered. Das ist normal, kein Fehler.
  1. Lege die SIP-Leitung host-/IP-basiert an, richte sie auf den Plattform-SIP-FQDN aus und weise die Nummer zu.
  2. Aktiviere CLIP No Screening, damit die echte Anrufer-ID durchgereicht wird statt der eigenen Nummer des Trunks.
  3. Für zeitbasiertes Routing zum Assistenten nutze eine Wahlkette mit Leitungspräfix wie **<line-digit>*<number>.
  4. Ist Audio einseitig oder fehlt ganz, setze Behind NAT? yes sowohl auf dem Starface-Server als auch auf der Leitung.
Nutze auf Starface niemals eine gewöhnliche PSTN-Anrufweiterleitung vom Assistenten aus, um einen Anruf zu übergeben – das erzeugt eine Anrufschleife zwischen Starface und der Plattform. Konfiguriere stattdessen jede Assistant-Übergabe auf einem Starface-Trunk als SIP-Transfer.
Wildix schickt Anrufe über einen statischen SIP-Trunk ohne Registrierung an die Plattform: Der Trunk zeigt auf den Plattform-SIP-FQDN und beantwortet die Authentifizierungsanfrage der Plattform mit dem eingehenden SIP-Benutzernamen und Passwort. Bei deaktivierter Registrierung zeigt WMS → Trunks den Trunk grau als nicht registriert an. Das ist normal, kein Fehler.Lege auf der Plattform pro DID einen SIP-Trunk an: Trunk-Typ Phone number (DID), die exakte +E.164-Nummer und SIP username/password als Inbound-Authentifizierung. Das Formular verlangt außerdem eine Termination address – trage dort den Hostnamen deiner Wildix-PBX ein. Wähle die SIP-Region EU, wenn deine PBX in Europa läuft, und weise dann einen Assistenten zu.In Wildix:
  1. Öffne WMS → Trunks und klicke unter der SIP-Trunk-Tabelle auf +.
  2. Setze Address or Host Name auf den Plattform-SIP-FQDN, ohne sip:-Präfix, und lass Enable registration deaktiviert.
  3. Trage den SIP-Benutzernamen des Plattform-Trunks als Auth Login und sein Passwort als Password ein. Lass From user leer: Wildix erzwingt diesen Wert im From-Header, sodass der Assistent ihn statt der Nummer des Anrufers sehen würde.
  4. Stelle unter Advanced den Transport auf TCP. Für verschlüsselte Anrufe nutze stattdessen TLS mit SDES-SRTP und aktiviere zusätzlich Secure trunking am Plattform-Trunk.
  5. Behalte unter Audio codecs nur alaw und ulaw – Wildix aktiviert standardmäßig g729, entferne ihn. Stelle DTMF mode auf rfc2833.
  6. Aktiviere Show original caller number, damit der Assistent die echte Anrufernummer sieht, nicht deine Wildix-Nummer. Aktiviere Support Refer and Hold, damit der Assistent Anrufe per Cold Transfer an Wildix-Benutzer zurückgeben kann.
  7. Lege im Wildix-Dialplan eine Regel an, die die exakte +E.164-DID über diesen Trunk anruft – zum Beispiel außerhalb der Geschäftszeiten über eine Timetable, als Überlauf aus einer Gruppe oder als IVR-Option.
Die Optionsbezeichnungen hängen von deiner WMS-Version ab. Der Wildix-Leitfaden zu Trunk-Einstellungen beschreibt jedes Feld.
Route die vollständige DID über den Trunk, im selben +E.164-Format wie am Plattform-Trunk. Nutze keine interne Kurzwahl wie 999 als Nummer, die Wildix wählt: Die Plattform akzeptiert nur die exakte DID, der Anruf erreicht den Assistenten also nie.
Diese Einrichtung deckt Anrufe von Wildix zum Assistenten ab. Ausgehende Assistenten-Anrufe über deine Wildix-Nummern sind noch kein bestätigtes Setup – wende dich an den Support, bevor du ausgehende Anrufe oder Kampagnen über Wildix planst.
Verbinde die Plattform als externen Trunk unter BYOC Carrier.
  1. Erstelle den Trunk mit Inbound (dem von Genesys Cloud generierten FQDN) und Outbound (ausgerichtet auf den Plattform-SIP-FQDN) als getrennt konfigurierten Legs.
  2. Öffne an deiner Firewall die nicht standardmäßigen Ports – TCP/UDP 32681 und TLS 32682 – statt der üblichen 5060/5061. Eine Firewall, die nur die Standardports öffnet, scheitert stillschweigend.
  3. Ordne die Codecs zuerst PCMU, dann PCMA, und entferne G.722.
  4. Beschränke die SIP Access Control auf ausschließlich die aktuellen Signalisierungsadressen der Plattform.
Setze SIP Access Control niemals auf Allow All. Ein offener Trunk wird typischerweise innerhalb von Stunden gefunden und für Toll Fraud missbraucht.
Die Plattform als externes SIP-Ziel auf einem Five9-SBC einzurichten, ist eine reine Enterprise-Integration.
  1. Eröffne ein Support-Ticket bei Five9 – es gibt keinen Self-Service-Weg.
  2. Stelle die Codecs ausschließlich auf G.711 (kein Opus/G.722).
  3. Konfiguriere Übergaben an Menschen mit SIP REFER – Five9 respektiert keine SIP-302-Redirects.
  4. Ziele bei jedem REFER auf eine vollqualifizierte URI (sip:queue@sbc-{region}.five9.com); eine bloße Nebenstelle wird stillschweigend verworfen.
Five9 beendet jeden Anruf hart nach exakt 12 Stunden, unabhängig von der Aktivität. Berücksichtige diese Obergrenze bei lange laufenden Flows und unbeaufsichtigten Kampagnenanrufen – von Plattformseite lässt sie sich nicht verlängern.
Aircall hat keinen Wholesale-SIP-Trunk. SIP Forwarding (nur im Enterprise-Tarif) deckt ausschließlich Inbound ab – es liefert Anrufe an die Plattform, aber Aircall hat keinen SIP-Weg, um einen Anruf mit einer Aircall-Nummer als Anrufer-ID wieder hinauszusenden. Um eine Nummer in beide Richtungen zu nutzen, portiere sie für Outbound zu einem SIP-fähigen Carrier (siehe SIP-Anbieter-Anleitungen) und behalte Aircall für Inbound. Aircall unterstützt außerdem kein SIP REFER – eine Übergabe sollte einen neuen ausgehenden Anruf aufbauen, statt einen Cold-SIP-Transfer zu versuchen.

Einrichtung testen

Rufe die DID von einem externen Telefon an und bestätige einen neuen eingehenden Datensatz in History, den zugewiesenen Assistenten und Audio in beide Richtungen. Führe bei Plattformen mit einem eigenen Outbound-Leg (3CX, Asterisk, Genesys Cloud) zusätzlich einen ausgehenden Testanruf durch – ein erfolgreicher Inbound-Test bestätigt nicht, dass Outbound korrekt konfiguriert ist, und umgekehrt. Siehe auch SIP-Anbieter-Anleitungen, BYO SIP-Trunk und Weitere und individuelle SIP-Anbieter. Quellen: 3CX-SIP-Trunks, Asterisk-Dokumentation, Starface-Wissensdatenbank, Wildix-Trunk-Einstellungen, Genesys BYOC Cloud, Five9-Dokumentation, Aircall-Support. Abgerufen am 22. August 2026, der Wildix-Leitfaden am 15. Oktober 2026.