Skip to main content
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 sechs 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-Trunk-Tab Options mit Transport Protocol auf TCP und deaktiviertem SRTP Mode

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

Reiche die echte Anrufer-ID mit OriginatorCallerID durch

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.
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, Genesys BYOC Cloud, Five9-Dokumentation, Aircall-Support. Abgerufen am 22. August 2026.