Ein explosionsgeschütztes SIP-Telefon kann den Status Registriert anzeigen, obwohl Anrufe nicht klingeln, ohne Ton verbunden werden oder nach der Annahme abbrechen. Registrierung, Rufaufbau, Medienübertragung und physischer Audioweg sind getrennte Prüfschritte. Ermitteln Sie die erste fehlerhafte Stufe, bevor Sie Einstellungen ändern oder das Telefon austauschen.
Beginnen Sie mit aus der Ferne verfügbaren Protokollen und einem freigegebenen Testanruf. Physische Prüfungen im explosionsgefährdeten Bereich erfordern fachkundiges Personal, betriebliche Erlaubnisse, Freischaltung und die Anweisungen des Geräts. Öffnen Sie kein unter Spannung stehendes Gehäuse und schließen Sie ohne die erforderlichen Schutzmaßnahmen keinen gewöhnlichen Laptop oder ein gewöhnliches Prüfgerät im Gefahrenbereich an. Eine Netzwerkdiagnose belegt nicht die Integrität des Explosionsschutzes.
Was die Registrierung nachweist und was ungeprüft bleibt
Eine erfolgreiche REGISTER-Transaktion bestätigt, dass ein Registrar den Registrierungsantrag akzeptiert hat. Prüfen Sie zum Verständnis des Ergebnisses die Contact-Zuordnungen und deren Ablauf. Authentifizierung ist üblich, doch 200 OK allein beweist nicht, dass sie stattgefunden hat. Der angezeigte Status kann eine frühere Aktualisierung statt der aktuellen Erreichbarkeit wiedergeben.
Ein Anruf benötigt weiterhin ein INVITE zum richtigen Ziel, eine akzeptable Sitzungsbeschreibung und einen funktionierenden Audioweg. Der Contact des Endgeräts, das Routing der PBX, ein Gateway oder SBC und das Medienziel können unterschiedliche Adressen und Regeln betreffen. Ein analoges explosionsgeschütztes Telefon an einem FXS-Gateway muss über dieses Gateway diagnostiziert werden; es ist selbst kein natives SIP-Endgerät.
Ordnen Sie das Fehlerbild vor einer Konfigurationsänderung ein
| Beobachtetes Fehlerbild | Zuerst zu erfassende Nachweise |
|---|---|
| Kein Klingeln oder sofortiger Fehler | Ausgehendes INVITE, Ziel, abschließende Antwort und PBX-Route. |
| Verbunden ohne Ton oder mit einseitigem Ton | SDP-Adressen und Ports, danach Medienankunft in jeder Richtung. |
| Anrufabbruch nach der Annahme | Zustellung von ACK, Absender von BYE, Transaktionszeitgeber und Plattformprotokolle. |
| Abgehackte oder zeitweise aussetzende Sprache | RTP-Sequenzlücken, Jitter, Verbindungslast und lokales Audioverhalten. |
Erfassen Sie Zeit, Rufnummern beider Seiten, Richtung, Firmware, Topologie und jüngste Änderungen. Prüfen Sie, ob interne, externe, Dispatch- und Beschallungsziele auf dieselbe Weise scheitern. Ein routenspezifischer Fehler unterscheidet sich von einem Fehler bei allen Anrufen. Sichern Sie einen fehlgeschlagenen Ablauf, bevor Sie neu starten oder die Konfiguration bearbeiten.
Schritt 1: Verfolgen Sie die Signalisierung bis zum ersten Fehler
Vergleichen Sie die gewählte Nummer mit dem tatsächlichen Request-URI und dem Rufnummernplan der PBX. Prüfen Sie Präfixe, Nummernumsetzung, Ausgangsberechtigungen und die Route zur vorgesehenen Nebenstelle oder zum Trunk. Bei eingehenden Fehlern prüfen Sie den aktuell registrierten Contact und ob das eingehende INVITE das Telefon erreicht.
Behandeln Sie Antwortcodes als Hinweise, nicht als vollständige Diagnosen. Ein erstes 401 oder 407 kann eine normale Authentifizierungsanforderung sein; untersuchen Sie eine Schleife oder einen abgewiesenen authentifizierten Folgeversuch. 403 bedeutet Ablehnung, 404 einen nicht gefundenen adressierten Benutzer oder eine nicht gefundene Domain, 408 Zeitüberschreitung und 480 vorübergehende Nichtverfügbarkeit. 488 kann Sitzungsmerkmale über einen einfachen Codec-Konflikt hinaus ablehnen. Lesen Sie Antwortdetails und Protokolle des erzeugenden Systems.
Erhält die PBX kein INVITE, vergleichen Sie DNS-Ergebnisse, VLAN, Gateway, Transport, Zielport und Zugriffsregeln. Empfängt sie die Anfrage, leitet sie aber nicht weiter, prüfen Sie Plattformrouting und Richtlinien. Prüfen Sie bei einem beantworteten INVITE die Nachrichten 200 OK und ACK auf den betreffenden Verbindungsabschnitten; die Anzeige Verbunden beweist nicht den Abschluss jedes Austauschs.
SIP verwendet häufig Port 5060 oder 5061 mit TLS, doch Installationen können andere Ports nutzen. Prüfen Sie den konfigurierten Transport und die lauschenden Dienste, statt einen angenommenen Portbereich freizugeben. Bei TLS kann ein gewöhnlicher Netzwerkmitschnitt den verschlüsselten SIP-Inhalt nicht offenlegen; nutzen Sie autorisierte Endgeräte- oder Serverdiagnosen.
Schritt 2: Vergleichen Sie SDP mit dem tatsächlichen Medienweg
Prüfen Sie das ausgehandelte SDP, einschließlich c=, m=, a=rtpmap und Richtungsattributen wie a=sendrecv. Prüfen Sie Verbindungsangaben auf Sitzungs- und Medienebene, akzeptierte Formate sowie abgelehnte oder inaktive Streams. Offer/Answer kann in unterschiedlichen SIP-Nachrichten erfolgen; gehen Sie nicht davon aus, dass INVITE und 200 OK stets die gesamte Aushandlung enthalten.
Prüfen Sie, ob jede angekündigte Medienadresse und jeder Port über die eingesetzte Topologie erreichbar ist. Eine private Adresse ist problematisch, wenn die Gegenstelle sie nicht erreichen kann, nicht allein deshalb, weil sie privat ist. Vergleichen Sie Pakete auf beiden Seiten einer Firewall- oder NAT-Grenze, um die Unterbrechung einer Richtung zu lokalisieren. Erlauben Sie die konfigurierten Medienflüsse; einen universellen RTP-Portbereich für alle Telefone gibt es nicht.
Ein SBC kann Medien verankern, wenn er entsprechend konfiguriert ist. STUN, TURN und ICE haben unterschiedliche Aufgaben und benötigen kompatible Unterstützung durch Endgerät und Plattform; keines ist eine universelle Option zur Behebung von NAT-Problemen. Prüfen Sie den Entwurf, bevor Sie SIP ALG oder das Firewall-Verhalten ändern, und halten Sie eine Rückkehr zur vorherigen Konfiguration bereit.
Vergleichen Sie akzeptierte Payload-Typen, Codec-Parameter, Paketierung und RTP/SRTP-Anforderungen auf jedem Abschnitt. Ein Gateway oder eine PBX kann nur transcodieren, wenn diese Funktion unterstützt und aktiviert ist. Eine SDP-Antwort kann mehrere Formate akzeptieren; die Annahme, jede Antwort wähle genau einen Codec aus, ist falsch. Leiten Sie unterstützte Codecs weder aus dem explosionsgeschützten Gehäuse noch von einem anderen Modell ab.
Stoppen Medien nach Halten, Vermittlung oder einem re-INVITE, vergleichen Sie neue SDP-Adressen, Ports und Richtung mit der ursprünglichen Sitzung. Bei zeitlich wiederkehrenden Abbrüchen prüfen Sie Freigabenachricht und Protokolle, bevor Sie einen Sitzungszeitgeber oder NAT-Ablauf verantwortlich machen. RTP-Verlust und Jitter beschreiben das Transportverhalten; beides beweist nicht, dass ein Mikrofon nutzbare Sprache erzeugt.
Schritt 3: Prüfen Sie die lokale Audiokette und erforderliche Dienste
Sobald Medien die richtigen Endgeräte erreichen, prüfen Sie Stummschaltung, Verstärkung, Hörer, Mikrofon, Lautsprecher und ausgewählten Audioausgang nach freigegebenen Verfahren. Bidirektionale Pakete können Stille oder nicht decodierbare Nutzdaten enthalten. Vergleichen Sie einen nachweislich funktionierenden Anruf und ein funktionierendes Endgerät, ohne den Austausch als Beweis eines Hardwarefehlers anzusehen; Zugangsdaten, Firmware, Switchport und Netzwerkeinstellungen können ebenfalls abweichen.
Prüfen Sie Hörer, Freisprechen und externe Beschallungsausgänge getrennt, soweit vorhanden. Ein funktionierender Hörer beweist nicht, dass ein externer Verstärker, Hornlautsprecherkreis oder Beschallungsrelais funktioniert. Standortanzeige im Dispatch, Aufzeichnung, Priorität und Alarmkopplung gehören zur Plattform oder Integration, sofern das konkrete Endgerät diese Funktionen nicht ausdrücklich selbst umsetzt.
Nutzen Sie synchronisierte Mitschnitte an geeigneten freigegebenen Punkten: Endgerätediagnose, gespiegelter Switchport, PBX oder SBC. Korrelieren Sie SIP Call-ID und Zeitstempel und beachten Sie, dass ein SBC unterschiedliche Verbindungsabschnitte erzeugen kann. Erfassen Sie nur benötigten Verkehr und schützen Sie Protokolle und Aufzeichnungen. Verschlüsseltes SRTP lässt sich aus einem gewöhnlichen Mitschnitt ohne autorisiertes Schlüsselmaterial und ein geeignetes Analyseverfahren nicht abhören.
Wiederholen Sie nach einer kontrollierten Änderung die fehlgeschlagene Route und beide Audiorichtungen. Prüfen Sie anschließend betroffene Beschallungs- oder Dispatch-Funktionen und die Wiederherstellung nach einer geplanten Umschaltung. Sichern Sie endgültige Einstellungen, Mitschnittreferenz und Ergebnis. Hinweise zu dauerhafter Überwachung und Konfiguration bietet der Beitrag zur Fernwartung explosionsgeschützter Beschallungstelefone.
Häufige Fragen
Warum funktionieren interne Anrufe, während externe scheitern?
Externe Anrufe ergänzen Trunk-Routing, Berechtigungen, Nummernumsetzung und vorgelagerte Richtlinien. Vergleichen Sie den funktionierenden internen Weg mit dem fehlgeschlagenen Trunk-Anruf einschließlich Rücksignalisierung und Medienabschnitten, statt anzunehmen, die Registrierung teste den Trunk.
Sollte jeder Fehler ohne Ton als Codec-Problem behandelt werden?
Nein. Stellen Sie zuerst die ausgehandelte Sitzung und die Medienankunft an jedem Endgerät fest. Routing, NAT, Zugriffsregeln, SRTP-Kompatibilität und lokales Audio können allesamt Stille verursachen. Eine Codec-Einstellung auf einer Webseite beweist nicht, was der Anruf ausgehandelt hat.
Ist ein Neustart eine Reparatur?
Ein Neustart kann einen Prozess wiederherstellen oder eine Zuordnung aktualisieren, identifiziert aber die Ursache nicht. Sichern Sie nach Möglichkeit zuerst Nachweise und prüfen Sie danach eine reproduzierbare Wiederherstellung. Dokumentieren Sie jede Dienstunterbrechung und organisieren Sie während der Wartung den alternativen Kommunikationsweg des Standorts.
Technische Referenzen
Protokollgrundlage: IETF RFC 3261, SIP und IETF RFC 3264, SDP Offer/Answer. Kontext zur Wartung im Gefahrenbereich: HSE-Hinweise zu Elektrizität in explosionsgefährdeten Atmosphären.
