> ## Documentation Index > Fetch the complete documentation index at: https://docs.famulor.io/llms.txt > Use this file to discover all available pages before exploring further. # SIP-Fehlerbehebung > Diagnose von Fehlern bei ausgehenden Anrufen, eingehenden Anrufen und Übergaben auf einem BYO-SIP-Trunk 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](/de/telephony/providers/fonial) und [Weitere und individuelle SIP-Anbieter](/de/telephony/providers/other-custom) 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](/de/telephony/providers/easybell#anrufe-weiterleiten), Hinweise zu Aircall/Five9 im [PBX-&-Contact-Center-Guide](/de/telephony/providers/pbx-and-contact-center). 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](/de/telephony/inbound-outbound#hinweise-bei-fehlern). ## Gängige SIP-Statuscodes | Status | Bedeutung | Typische Ursache | | --------- | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | 401 / 407 | Authentifizierung fehlgeschlagen | Falscher SIP-Benutzername/Passwort, oder Zugangsdaten wurden nur auf einer Seite geändert | | 403 | Forbidden | Ziel vom Trunk nicht erlaubt – Geo-Berechtigungen, eine nicht verifizierte Anrufer-ID oder eine Quell-IP außerhalb der Allowlist | | 404 | Not found | Die gewählte DID/Extension entspricht nicht der Konfiguration, oder das Ziel existiert nicht | | 405 | Method not allowed | Die Gegenstelle unterstützt die verwendete SIP-Methode nicht. Bei einer Übergabe bedeutet das fast immer: Der Trunk unterstützt kein SIP REFER | | 408 | Request timeout | Keine Antwort innerhalb des Klingelfensters | | 480 | Temporarily unavailable | Ziel erreichbar, aber aktuell nicht verfügbar | | 486 / 600 | Busy | Besetzt | | 487 | Request terminated | Der Anruf wurde vor der Annahme abgebrochen | | 503 | Service unavailable | Der Trunk selbst hat die Anfrage abgelehnt – häufig bei einem vom Anbieter nicht unterstützten SIP REFER oder einem Ausfall auf Anbieterseite | Diese Codes entsprechen den anbieterneutralen Fehlercodes der Plattform (`busy`, `no_answer`, `authentication_failed`, `destination_forbidden`, `trunk_unavailable`, …), beschrieben unter [Eingehende & ausgehende Anrufe](/de/telephony/inbound-outbound#hinweise-bei-fehlern). ## 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.