Skip to main content
Arbeite zuerst Outbound, dann Inbound ab. Outbound isoliert Zugangsdaten, Transport und Codecs, bevor Routing-Variablen (FQDN, Quell-IPs, DID-Matching) dazukommen – die meisten Trunks laufen ausgehend in wenigen Minuten.

​
Die Plattform sendet nie SIP REGISTER

Die Plattform authentifiziert jeden Anruf direkt, pro Request – sie registriert sich nie bei deinem Anbieter und erwartet auch keine Registrierung vom Anbieter. Zeigt das Dashboard deines Anbieters den Trunk oder SIP-Nutzer nach der Einrichtung als Offline / Nicht registriert, ist das erwartet, kein Fehler: Eingehende Anrufe kommen über das konfigurierte Ziel (den Plattform-SIP-FQDN) an, nicht über eine Registrierung. Mehrere Anbieteranleitungen weisen das explizit aus, weil es auf den ersten Blick kaputt wirkt – siehe Fonial und Weitere und individuelle SIP-Anbieter für Beispiele.

​
Ausgehende Anrufe verbinden nicht

  1. Prüfe zuerst Terminierungshost, Transport (UDP/TCP/TLS) und Zugangsdaten gegen die Dokumentation des Anbieters – ein falscher Transport oder ein zusätzliches sip:-Präfix bzw. ein Port an der Terminierungsadresse ist die häufigste Ursache.
  2. Bestätige, dass das Format der ausgehenden Rufnummer (international mit +, international ohne +, oder national) zu den Erwartungen des Anbieters für diesen Trunk passt – manche Carrier lehnen ein falsches Format still ab, andere nehmen den Anruf an und brechen ihn dann ab.
  3. Verlangt der Anbieter Anrufe von einer einzigen, whitelisteten Quell-IP, aktiviere Fixed outbound IP explizit. Die Plattform hat sonst keine statische ausgehende IP, weshalb eine anbieterseitige IP-Allowlist ohne diesen Schalter jeden Anruf scheitern lässt.
  4. Vergleiche die Codecs: Ein Anbieter, der nur G.711 akzeptiert, lehnt einen Anruf mit noch aktiviertem Opus/G.722 ab oder liefert nur einseitiges Audio.
  5. Ändere jeweils nur eine Einstellung und mache danach einen einzelnen Testanruf – History zeigt den exakten SIP-Statuscode, was die Ursache deutlich schneller eingrenzt als Raten.

​
Eingehende Anrufe erreichen den Assistenten nicht

  • Sende an den FQDN der Plattform, niemals an eine rohe IP-Adresse. Das Senden an eine IP ist die häufigste Ursache für eingehende Fehlschläge und scheitert auf beiden Seiten still – kein Anruf erscheint jemals in History.
  • Bei Provider source IPs muss jede aktuelle Signalisierungs-IP/-CIDR eingetragen sein. Eine veraltete oder unvollständige Liste lässt Anrufe ohne klare Fehlermeldung fallen, statt sie laut abzulehnen.
  • Bestätige, dass die DID exakt dem entspricht, was der Anbieter sendet – ein SIP-Extension-Trunk benötigt außerdem seine Primary DID, da er kein Wildcard ist.
  • Kommt in History gar nichts an (nicht einmal ein fehlgeschlagener Anruf), erreicht der Anbieter die Plattform noch nicht – prüfe zuerst dessen eigene Outbound-/Weiterleitungsregel, bevor du ein plattformseitiges Auth-Problem annimmst.

​
Anrufübergaben schlagen fehl (SIP REFER)

Schlägt eine Cold- oder Warm-Übergabe fehl, während normale Anrufe problemlos funktionieren, liegt es fast immer an einem der folgenden Punkte, in dieser Reihenfolge:
  1. Der Trunk unterstützt kein SIP REFER. Das ist nicht bei jedem Carrier der Fall – ein durchgespieltes Beispiel findest du im Easybell-Guide, Hinweise zu Aircall/Five9 im PBX-&-Contact-Center-Guide. Ist das die Ursache, hilft keine Änderung am Zielformat: Stelle diese Übergabe auf Warm Transfer um – dabei baut die Plattform einen neuen ausgehenden Anruf auf und verbindet ihn, statt den bestehenden Anruf per REFER weiterzugeben.
  2. Das SIP-URI-Format. Wird REFER unterstützt, schlägt die Übergabe aber trotzdem fehl, probiere der Reihe nach: mit Port (sip:+1234567890@sip-server:5060), ohne Port, dann ein reines sip:+1234567890.
  3. Das Ziel selbst. Bestätige, dass die Zielnummer erreichbar und nicht blockiert ist, bevor du den Trunk verantwortlich machst.
Jede versuchte Übergabe – erfolgreich oder nicht – hinterlässt call_transfer_failed oder warm_transfer_failed im Ereignisprotokoll des Anrufs; die gemeinsame Fehlerstruktur findest du unter Eingehende & ausgehende Anrufe.

​
Gängige SIP-Statuscodes

Diese Codes entsprechen den anbieterneutralen Fehlercodes der Plattform (busy, no_answer, authentication_failed, destination_forbidden, trunk_unavailable, …), beschrieben unter Eingehende & ausgehende Anrufe.

​
Allgemeine Konnektivität

  • Bestätige, dass das Netzwerk hinter dem Trunk eine funktionierende Internetverbindung hat.
  • Stelle sicher, dass keine Firewall ausgehenden SIP-Verkehr blockiert – eine Firewall, die nur die Standardports (5060/5061) öffnet, verwirft still Anbieter mit nicht standardmäßigen Signalisierungsports (z. B. Genesys Cloud mit 32681/32682).

​
Vor dem Support-Kontakt

  • Outbound: Zugangsdaten verifiziert, richtiger Trunk-/Phone-Typ gewählt, Fixed outbound IP konfiguriert, falls vom Anbieter gefordert, ein direkter Testanruf durchgeführt.
  • Inbound: Authentifizierungsmethode konfiguriert (Quell-IPs oder Benutzername/Passwort), bei IP-Auth jede aktuelle Anbieter-IP eingetragen, Anbieter sendet nachweislich an den FQDN (nicht an eine IP), ein Testanruf von einer externen Nummer durchgeführt.
  • Allgemein: Netzwerkverbindung bestätigt, Firewall ausgeschlossen.

​
Hilfe erhalten

Gib beim Support-Kontakt an:
  • Die Call-ID aus History.
  • Die exakte Trunk-Konfiguration (Typ, Transport, Auth-Methode).
  • Testergebnisse für beide Richtungen (ausgehend und eingehend).
  • Bei Übergabeproblemen das exakte SIP-URI-Format, das du ausprobiert hast.
Teste eingehende und ausgehende Anrufe unabhängig voneinander – dass der eine funktioniert, bestätigt nie den anderen.