Bei der Wartung eines SIP-Ex-Telefons bestätigt eine 200 OK-Antwort auf eine REGISTER-Transaktion lediglich, dass das Endgerät erfolgreich eine authentifizierte Adressbindung mit dem Registrierungsserver hergestellt hat. Sie garantiert weder, dass ein INVITE korrekt geroutet werden kann, noch dass SDP einen kompatiblen Codec aushandelt oder RTP-Medien in beiden Richtungen zwischen dem Ex-Telefon und der Gegenstelle übertragen werden können. Anders gesagt beschreibt „Registriert“ nur einen Teil der Erreichbarkeit auf der SIP-Steuerungsebene, nicht die vollständige Ende-zu-Ende-Telefoniefähigkeit.
Deshalb kann ein Ex-Telefon ordnungsgemäß registriert erscheinen und dennoch nicht klingeln, eine Verbindung ohne Ton aufbauen, nur einseitige Sprache übertragen oder unmittelbar nach dem Abheben trennen. In vielen Fällen ist der Registrierungsserver nicht die eigentliche Fehlerquelle. Das Problem liegt im Signalisierungspfad, Medienpfad oder in der lokalen Audiokette nach der Registrierung. Eine Fehlersuche in drei Ebenen — Signalisierung, Medien und Endgeräte-Audio — zerlegt die unscharfe Meldung „registriert, aber keine Anrufe möglich“ in unabhängig prüfbare Schritte und verhindert wiederholte Neustarts des Geräts in die falsche Richtung.
Warum bedeutet „Registriert“ nicht automatisch, dass das Telefon Anrufe führen kann?
Zunächst ist zu klären, was die Registrierung tatsächlich bewirkt. Eine vom Endgerät gesendete REGISTER-Anfrage enthält normalerweise mehrere wichtige Felder: Request-URI zur Kennzeichnung der Registrierungsdomäne; To für das registrierte Konto bzw. den Address-of-Record (AOR); Contact für die aktuell erreichbare Adresse des Endgeräts, typischerweise IP-Adresse und Port; sowie Expires für die Gültigkeitsdauer der Registrierung.
Die Registrierung ist kein einmaliger Vorgang. Die Plattform speichert im Standortdienst eine Zuordnung, nach der ein bestimmter AOR aktuell über einen bestimmten Contact erreichbar ist. Diese Bindung besitzt eine Ablaufzeit, häufig etwa eine Stunde. Das Endgerät muss die Registrierung vor Ablauf erneuern. Geschieht dies nicht, kann die Plattform die Nebenstelle schließlich als nicht erreichbar betrachten.
Die Authentifizierung erfolgt häufig in zwei Austauschschritten. Zuerst sendet das Endgerät REGISTER ohne Zugangsdaten; der Server antwortet mit 401 Unauthorized und Challenge-Parametern wie realm und nonce. Das Endgerät berechnet mit den Kontodaten den Authentifizierungs-Digest und sendet erneut REGISTER mit einem Authorization-Header. Erst danach erhält es normalerweise 200 OK. Aus Signalisierungssicht bedeutet „Registrierung erfolgreich“ somit lediglich, dass Endgerät und Server gerade eine authentifizierte REGISTER-Transaktion abgeschlossen haben.
Für ein echtes Telefongespräch ist deutlich mehr erforderlich. Beim Wählen muss das Endgerät ein INVITE erzeugen. PBX, SIP-Server oder Leitstellenplattform müssen die Zielrufnummer anhand von Nummerierungs- und Berechtigungsregeln routen. Anschließend handeln beide Seiten per SDP Codec, Medienadresse und RTP-Port aus, bevor Sprache tatsächlich übertragen werden kann.
Signalisierung und Medien nutzen außerdem getrennte Pfade. SIP-Signalisierung verwendet üblicherweise UDP/TCP 5060 oder TLS 5061, RTP dagegen einen separaten Bereich dynamischer UDP-Ports. Gibt eine Firewall Port 5060 frei, blockiert jedoch den RTP-Bereich, kann die Registrierung fehlerfrei funktionieren, während im Gespräch kein Ton vorhanden ist.
REGISTER erfolgreich
→ SIP-Konto wird als erreichbar angezeigt
→ INVITE kann trotzdem abgewiesen werden
→ Selbst wenn 200 OK zurückkommt
→ RTP kann weiterhin durch Firewall, NAT oder eine falsche Medienadresse blockiert sein
→ Selbst wenn RTP das Endgerät erreicht
→ Lokales Mikrofon oder Lautsprecher können weiterhin defekt sein
Der Kernpunkt ist einfach: Der Registrierungsstatus ist eine Momentaufnahme, die zeigt, dass eine Transaktion zu einem bestimmten Zeitpunkt erfolgreich war; er ist kein Nachweis für Ende-zu-Ende-Sprachverfügbarkeit. Er beweist nicht einmal, dass das Netz exakt jetzt erreichbar ist, denn die Registrierung wird periodisch erneuert und die Anzeige „Registriert“ kann lediglich den letzte erfolgreiche Aktualisierung widerspiegeln.
Zuerst klären, ob der Fehler im Rufaufbau oder im Sprachmedienpfad liegt
Wenn gemeldet wird, ein Telefon sei „registriert, könne aber nicht telefonieren“, sollte der erste Schritt nicht darin bestehen, Codecs oder Netzparameter zu verändern. Zunächst muss genau geklärt werden, was „kann nicht telefonieren“ bedeutet. Einige wenige Fragen geben meist schon vor dem Einsatz von Werkzeugen die richtige Richtung für die Fehlersuche vor.
Ein vollständiger SIP-Anruf lässt sich in zwei Hauptphasen teilen. Die erste ist der Rufaufbau, beginnend mit INVITE bis zur 200-OK-Antwort der angerufenen Seite und dem ACK des Anrufers. Die zweite sind die Sprachmedien: Die SDP-Aushandlung ist abgeschlossen und bidirektionales RTP sollte tatsächlich fließen. Die einfachste Trennlinie ist die Frage, ob die Benutzeroberfläche den Anruf als verbunden anzeigt.
Erscheint beim Wählen sofort ein Fehler, klingelt nichts oder sieht die Gegenstelle gar keinen eingehenden Anruf, liegt das Problem wahrscheinlicher in der SIP-Signalisierung oder im Rufrouting. Zeigen beide Seiten den Anruf als verbunden und läuft der Gesprächszähler, jedoch ohne Audio oder nur mit einseitigem Audio, muss die Fehlersuche auf den SDP- und RTP-Medienpfad wechseln.
| Symptom | Wahrscheinliche Phase | Erste Prüfungen |
|---|---|---|
| Sofortiger Wahlfehler / kein Klingeln / Gegenstelle erhält nichts | Rufaufbau | Nummern-Routing, Berechtigungen, SIP-Antwortcodes, Signalisierungserreichbarkeit |
| Anruf wird als verbunden angezeigt, aber kein Audio | Sprachmedien | SDP-Medienadresse, RTP-Ports, Firewall, NAT, Codec |
| Anruf wird verbunden, Audio jedoch nur in eine Richtung | Sprachmedien | SDP, RTP, NAT-Zuordnung und aufgezeichnete Medien je Richtung vergleichen |
| Anruf trennt nach einigen Sekunden | Rufaufbau + Medien | ACK, Session Timer, NAT-Timeout, Freigaberichtlinie der Plattform |
| Audio stockt oder ist intermittierend | Medientransportqualität | Paketverlust, Jitter, Latenz, Bandbreite und RTP-Portänderungen |
Zwei weitere Muster sind hilfreich. Kann das Telefon ausgehend telefonieren, aber keine Anrufe empfangen, liegt die Ursache häufig beim eingehenden Nummern-Routing, der Contact-Adresse, NAT oder dem Plattform-Routing. Kann es empfangen, aber nicht ausgehend telefonieren, sind Dialplan, Ausgangsberechtigungen, Nummernformat oder SIP-Trunk-Konfiguration zu prüfen.
Können normale SIP-Nebenstellen untereinander telefonieren, aber Anrufe zur Leitstellenkonsole, zum Beschallungssystem oder zum PSTN scheitern, ist der Fehlerbereich deutlich kleiner und betrifft wahrscheinlich eine bestimmte Route oder Systemschnittstelle.
Ein sinnvoller Feldbericht sollte daher vier Fragen beantworten:
Tritt der Fehler bei ausgehenden oder eingehenden Anrufen auf?
Klingelt der Anruf?
Zeigt die Oberfläche den Anruf als verbunden an?
Fehlt Audio vollständig, ist es einseitig oder wird der Anruf nach einigen Sekunden getrennt?
Diese vier Antworten sind wesentlich hilfreicher als die Aussage „das Telefon funktioniert nicht“.
Wenn der Rufaufbau scheitert: zuerst Nummer, Berechtigung oder SIP-Antwort prüfen?
Tritt das Problem während des Rufaufbaus auf, folgen Sie zunächst dem SIP-Signalisierungspfad, bevor Sie die Hardware des Ex-Telefons verdächtigen. Eine praktische Reihenfolge ist: Nummer → Berechtigungen → Antwortcode → Signalisierungserreichbarkeit.
Beginnen Sie mit Nummer und Dialplan. Entspricht die vom Endgerät gesendete Request-URI den Erwartungen der Plattform? Braucht die Nebenstelle ein Präfix? Erfordert systemübergreifendes Wählen eine Vorwahl, einen Zugriffscode oder eine Nummernumsetzung? Viele Fälle „registriert, aber kein ausgehender Anruf möglich“ gehen letztlich auf einen Unterschied zwischen dem vom Telefon gesendeten Nummernformat und den im PBX konfigurierten Routingregeln zurück.
Beispielsweise kann das Telefon 8001 senden, während der PBX 8#8001 oder eine vollständige Nummer im E.164-Format erwartet. Eine Paketerfassung mit der INVITE-Request-URI bestätigt dies sofort.
Prüfen Sie danach die Kontoberechtigungen. Manche Nebenstellen dürfen nur intern telefonieren und besitzen keine PSTN-Berechtigung. Andere können normale SIP-Nebenstellen erreichen, jedoch keine Notfall-Hotlines, Leitstellengruppen oder Beschallungszonen. Solche Class-of-Service-Einstellungen werden in Industrieprojekten leicht übersehen, weil die Registrierung diese geschäftlichen Berechtigungen nicht testet. REGISTER beantwortet „Ist dieses Konto erreichbar?“, der Anrufversuch dagegen „Darf dieses Konto dieses Ziel anrufen?“.
Anschließend helfen SIP-Antwortcodes, den Fehler weiter einzugrenzen:
| Klasse | Häufige Antworten | Typische Richtung |
|---|---|---|
| 1xx Information | 100 Trying, 180 Ringing, 183 Session Progress | Rufaufbau läuft; Problem kann weiter hinten oder medienbezogen sein |
| 2xx Erfolg | 200 OK | Rufaufbau erfolgreich; zur Medienfehlersuche wechseln |
| 4xx Client-Fehler | 401/407 Authentifizierung, 403 Berechtigung, 404 nicht gefunden, 408 Timeout, 480 nicht verfügbar, 486 besetzt, 488 Codec-Konflikt | Häufig Endgerätekonfiguration, Routing oder Dienstrichtlinie |
| 5xx Server-Fehler | 500, 503 Service Unavailable | PBX-, SBC- oder Leitstellenplattform-Seite |
| 6xx Globaler Fehler | 603 Decline | Ziel weist den Anruf ausdrücklich ab |
Einige Antworten treten bei der Fehlersuche besonders häufig auf. 401/407 weisen meist auf Probleme mit der Authentifizierungs-Challenge hin, etwa Zugangsdaten, Algorithmus oder Kontobindung. 403 lenkt die Prüfung auf Berechtigungsregeln, Kontorichtlinien oder den Ablehnungsgrund der Plattform. 404 kann bedeuten, dass die Nummer nicht existiert oder keine Route passt. 408 und 480 deuten auf Timeout oder Nichterreichbarkeit des Benutzers hin. 488 steht häufig für inkompatible Medienfähigkeiten oder fehlgeschlagene Codec-Aushandlung.
Erscheint die SIP-Konfiguration korrekt, aber INVITE erreicht das Zielsystem nie, ist zum Netzwerkpfad zurückzukehren. Prüfen Sie VLAN, Gateway, Firewall, ACL-Regeln und die tatsächlich vom Telefon verwendete Zieladresse. Der schnellste Test ist eine Erfassung auf der Serverseite. Kommt INVITE an, wird aber nicht weitergeleitet, ist das Routing im PBX oder der Leitstellenplattform zu untersuchen. Kommt INVITE gar nicht an, liegt der Schwerpunkt auf Endgerät oder Netzwerkpfad zwischen Endgerät und Server.
Wenn der Anruf verbunden ist, aber kein oder nur einseitiges Audio vorhanden ist: Was prüfen?
„Beide Seiten zeigen verbunden, aber es ist kein Ton da“ gehört zu den häufigsten SIP-Fehlern. Zu diesem Zeitpunkt ist die Rufsignalisierung üblicherweise erfolgreich abgeschlossen. Das Problem liegt eher in der SDP-Aushandlung oder dem RTP-Transport. Die Fehlersuche muss von der Signalisierungs- auf die Medienebene wechseln.
Beginnen Sie mit den in SDP enthaltenen Medieninformationen. Besonders wichtig sind: c= für die Verbindungsadresse, m= für Medienart und Port, a=rtpmap für die Zuordnung von Payload Types zu Codecs und a=sendrecv/sendonly/recvonly für die Medienrichtung.
Die vom Endgerät im INVITE oder 200 OK per SDP angekündigte Audioadresse muss von der Gegenstelle erreichbar sein. Trägt das Endgerät eine nicht routbare private Adresse wie 192.168.x.x ein, während die Gegenstelle in einem anderen Netz liegt, kann der SIP-Anruf trotzdem aufgebaut werden, obwohl der RTP-Strom das Ziel nie erreicht. Das ist ein klassischer Fall von „verbunden, aber kein Audio“.
NAT-Umgebungen sind dafür besonders anfällig; die Behandlung hängt von der Netzarchitektur ab. SIP-Signalisierung kann NAT erfolgreich passieren, während der Medienpfad vollständig scheitert. Häufige NAT-Verhaltensweisen sind Full Cone, Restricted Cone, Port Restricted Cone und Symmetric NAT mit zunehmend schwieriger Durchquerbarkeit.
Industrienetze lösen dies häufig mit einem SBC als Medienrelais, sodass RTP über einen bekannten Punkt verankert wird. Andere Umgebungen nutzen STUN zur Ermittlung öffentlicher Adresszuordnungen, komplexere Installationen TURN oder ICE. Der richtige Mechanismus hängt von der realen Topologie ab. Ein erfolgreiches REGISTER beweist nicht, dass RTP NAT durchqueren kann.
Firewalls sind eine weitere häufige Ursache. Manche Projekte öffnen nur 5060 oder 5061, weil dies die offensichtlichen SIP-Ports sind, während Sprache einen völlig separaten RTP-Bereich verwendet. Viele Geräte weisen RTP-Ports dynamisch aus Bereichen wie 10000–20000 zu. Ist SIP erlaubt, RTP aber durch eine ACL blockiert, entsteht genau das gemeldete Bild: „Anruf verbunden, aber kein Audio“.
Einseitiges Audio ist richtungsbezogen zu untersuchen. Hört die Leitstelle das Feldtelefon, der Feldnutzer aber nicht die Leitstelle, funktioniert bereits mindestens eine RTP-Richtung oder ein lokaler Audiopfad. Statt das gesamte Netz erneut zu prüfen, vergleichen Sie beide SDP-Adressen, RTP-Ports, NAT-Zuordnungen und erfassten Medienströme. Richtungsunterschiede weisen oft direkt auf NAT-Zuordnung, Firewall-Regel oder eine falsche SDP-Adresse einer Seite hin.
Nach der Netzwerkprüfung Codec und lokale Audiokette kontrollieren
Das Vorhandensein von RTP-Paketen garantiert keine verständliche Sprache. Als Nächstes ist zu bestätigen, dass beide Seiten tatsächlich einen kompatiblen Codec ausgehandelt haben.
Die Codec-Aushandlung folgt dem SDP-Angebots-/Antwortmodell. Das anrufende Endgerät listet die unterstützten Codecs im INVITE-SDP normalerweise in Präferenzreihenfolge auf. Das angerufene Endgerät wählt einen ebenfalls unterstützten Codec und gibt ihn im 200 OK zurück. Gibt es keine gemeinsame Schnittmenge, scheitert die Medienaushandlung.
Typische Codecs in industriellen Ex-Telefonen sind G.711 (PCMU/PCMA, 64 kbps und breit kompatibel mit PSTN-Umgebungen), G.729 für Verbindungen mit geringerer Bandbreite, G.722 für Breitbandsprache und Opus auf einigen neueren Geräten. Ist am Telefon nur eine Codec-Gruppe aktiviert, während PBX, Aufzeichnungssystem oder Leitstellenplattform eine andere unterstützen, kann 488 Not Acceptable Here zurückgegeben werden oder bei manchen Implementierungen ein verbundener Anruf mit fehlerhaften Medien entstehen.
Die richtige Methode ist, Payload Types und Codec-Listen beider SDP-Nachrichten zu vergleichen, statt sich nur auf eine Verwaltungsseite zu verlassen, die einen Codec als aktiviert anzeigt.
Sind Codec-Aushandlung und RTP-Transport bestätigt, geht es zum physischen Audiopfad des Endgeräts. Ex-Telefone arbeiten oft lange Zeit in lauten, feuchten, staubigen oder korrosiven Umgebungen. Mikrofon, Handapparat, Lautsprecher, Verstärkermodul, Steckverbinder oder Feldkabel können ausfallen, auch wenn der SIP-Stack einwandfrei arbeitet.
Eine praktische Methode ist der Vergleich der RTP-Statistik mit dem tatsächlich vor Ort hörbaren Signal. Zeigt die Erfassung kontinuierliches bidirektionales RTP mit normalen Paketzahlen und Zeitabständen, aber eine Seite bleibt stumm, prüfen Sie Stummschaltung, Pegel und physisches Mikrofon bzw. Lautsprecher. Wird RTP gesendet, der Audioinhalt ist jedoch faktisch still, ist auch die Mikrofonaufnahme bzw. Audioerfassungskette zu untersuchen.
Bei quantitativer Medienanalyse sind drei Werte besonders hilfreich: Paketverlust, Jitter und Einweg-Latenz. Mit zunehmendem Paketverlust wird Sprachqualität hörbar schlechter; zu hoher Jitter kann einen größeren Jitterpuffer erfordern, und hohe Einweg-Latenz erschwert natürliche Gespräche. Konzentriert sich der Verlust auf einen bestimmten Netzhop, kommen Linküberlastung oder Funktransport als Ursache infrage.
Bei Ex-Beschallungsstationen mit verstärktem Ausgang ist zudem zwischen dem eingebauten Telefonlautsprecher und einem externen Horn- oder Verstärkerausgang zu unterscheiden. Beide verwenden nicht zwingend genau denselben Audiopfad. Normales Hörer- oder Freisprechen beweist nicht, dass externe Beschallung funktioniert, und umgekehrt. Inbetriebnahme und Fehlersuche sollten jeden benötigten Audiopfad separat prüfen, anstatt jede Meldung „keine Beschallung“ als SIP-Fehler zu behandeln.
Wie kann eine Paketerfassung den Fehlerbereich schnell eingrenzen?
Bei komplexen SIP-Fehlern ist wiederholtes Ändern von Parametern meist weniger wirksam als die vollständige Aufzeichnung eines fehlgeschlagenen Anrufs und dessen chronologische Verfolgung von REGISTER bis BYE. Wireshark genügt für die meisten Fälle. Sinnvolle Erfassungspunkte sind Telefonseite, gespiegelter Netzwerkport sowie SBC- oder PBX-Seite.
Der Erfassungsort bestimmt, was sich beweisen lässt. Eine Aufzeichnung am Endgerät zeigt exakt, was das Telefon gesendet und empfangen hat, und hilft bei der Frage, ob der Fehler lokal entsteht. Eine Aufzeichnung am SBC oder PBX zeigt, ob die Plattform die Signalisierung korrekt empfangen und weitergeleitet hat. Bei Installationen über VLANs, Standorte oder einen SBC sind mehrere Erfassungspunkte vorzuziehen, denn ein einzelner Punkt beweist nur, dass eine Nachricht dort angekommen ist, nicht dass das nächste Netzsegment korrekt funktioniert hat.
Sobald die Aufzeichnung vorliegt, folgen Sie dem Anruf in dieser Reihenfolge:
1. War REGISTER erfolgreich?
→ 2. Wurde INVITE tatsächlich gesendet?
→ 3. Hat der PBX es empfangen und korrekt geroutet?
→ 4. Hat die Gegenstelle 18x / 200 OK zurückgegeben?
→ 5. Hat SDP einen gemeinsamen Codec ausgehandelt?
→ 6. Ist tatsächlich bidirektionales RTP vorhanden?
→ 7. Sind RTP-Ziel-IP-Adressen und Ports korrekt?
→ 8. Übertragen Feldmikrofon und Lautsprecher tatsächlich Audio?
Wireshark bietet dafür nützliche Werkzeuge. SIP-Nachrichten lassen sich mit Filtern wie sip oder sip.CSeq anzeigen. Unter Telephony → VoIP Calls kann ein Anruf zusammen mit seiner Signalisierungsfolge und den zugehörigen RTP-Strömen geprüft werden. Die RTP-Analyse zeigt zudem Paketverlust, Jitter und weitere Qualitätsindikatoren.
Die Reihenfolge der Fehlersuche sollte zuerst Signalisierung, dann Medien bleiben. Scheitert die Signalisierung, liegt das Problem im Rufaufbau. Ist die Signalisierung erfolgreich, aber Medien fehlen, gehört die Untersuchung in den Medienpfad.
Bei „ausgehend funktioniert, eingehend nicht“ ist zu prüfen, ob das eingehende INVITE das Ex-Telefon tatsächlich erreicht. Bricht der Anruf regelmäßig nach wenigen oder einigen Dutzend Sekunden ab, prüfen Sie ACK, Session Timer, NAT-Zuordnung und ob die Plattform die Sitzung freigibt, weil eine erwartete Nachricht fehlt.
Ein weniger offensichtlicher Fall ist die Medien-Neuaushandlung während des Gesprächs. Ein re-INVITE kann RTP-Adresse oder Port ändern. Scheitert dabei eine NAT-Zuordnung, kann das Symptom lauten: „Der Anruf funktionierte einige Sekunden, dann verschwand der Ton.“
Ziel ist nicht, jeden SIP-Antwortcode auswendig zu lernen. Stellen Sie immer dieselbe Frage: Welche letzte Ebene hat dieser Anruf erfolgreich passiert, und wo trat das erste abnormale Verhalten auf? Sobald der erste Fehlerpunkt gefunden ist, ist ein großer Teil der Fehlersuche bereits erledigt.
Häufige Fragen
Beweist der Status „Registriert“ bei einem SIP-Telefon zumindest, dass das Netzwerk funktioniert?
Nein. Registriert zeigt nur, dass das Endgerät zu einem bestimmten Zeitpunkt eine SIP-Registrierungstransaktion mit dem Registrar abschließen konnte. Es beweist nicht, dass Rufrouting, Zielerreichbarkeit, RTP-Medien, NAT, Firewall-Regeln oder Audiohardware des Endgeräts funktionieren. Ebenso beweist es nicht, dass das Netz während eines tatsächlichen Gesprächs frei von Paketverlust oder hoher Latenz bleibt. Da Registrierung periodisch erfolgt, kann der angezeigte Status lediglich den letzte erfolgreiche Aktualisierung widerspiegeln.
Beide Seiten zeigen „verbunden“, aber es gibt keinen Ton. Was zuerst prüfen?
Prüfen Sie zuerst Medien-IP-Adressen, RTP-Ports und Codec-Aushandlung im SDP. Bestätigen Sie anschließend, dass Firewall, NAT-Gerät oder SBC bidirektionales RTP zulassen. Erreicht bidirektionales RTP sicher beide Endgeräte, gehen Sie zu Mikrofon, Lautsprecher, Stummschaltung und lokalen Audioausgabeeinstellungen über. Praktisch gilt: zuerst Medienpfad, dann lokale Hardware.
Warum kann dasselbe Ex-Telefon intern telefonieren, aber PSTN-Anrufe schlagen fehl?
Interne Nebenstellenanrufe und PSTN-Anrufe verwenden üblicherweise unterschiedliche Routingpfade. Externe Anrufe benötigen außerdem Ausgangsberechtigungen, Nummernumsetzung, SIP-Trunk-Konfiguration, Provider-Routing und Regeln zur Anruferkennung. Ein erfolgreicher Nebenstellenanruf beweist nur, dass ein Teil des SIP- und Medienpfads funktioniert. PSTN-Anrufe müssen weiterhin Trunk und Providernetz durchlaufen und unterliegen zusätzlichen Routing- und Richtlinienanforderungen.
Registrierung ist normal, aber Audio stockt oder der Anruf bricht mittendrin ab. Was kann die Ursache sein?
Häufig liegt es an der Medientransportqualität: Paketverlust, übermäßiger Jitter, unzureichende Bandbreite oder abgelaufene NAT-Zuordnung können RTP während des Anrufs unterbrechen. Prüfen Sie zuerst RTP-Verlust und Jitter, danach Linkkapazität und gegebenenfalls Funkabdeckung. Brechen Anrufe stets nach einem vorhersehbaren Intervall ab, prüfen Sie auch die Medien-Neuaushandlung per re-INVITE und das Verhalten des Session Timers.
Warum behebt ein Austausch des Telefons das Problem, während das ursprüngliche Gerät weiter ausfällt?
Das deutet häufig auf Konfiguration, Firmware oder lokale Hardware des ursprünglichen Telefons statt auf das Netz hin. Mögliche Ursachen sind Firmwarefehler, falsche SIP-Parameter wie Registrierungsablauf, NAT-Behandlung oder RTP-Portbereich oder ein Defekt im DSP bzw. Audiomodul. Vergleichen Sie beide Geräte Einstellung für Einstellung, insbesondere Codec-Listen, SIP-Ports und NAT-Einstellungen, statt den Unterschied sofort einem instabilen Netz zuzuschreiben.
Ist ein Neustart eines SIP-Ex-Telefons eine sachgerechte Fehlersuchmethode?
Ein Neustart kann manchmal vorübergehend die Registrierung wiederherstellen, eine NAT-Zuordnung erneuern oder einen hängenden Prozess lösen, sollte aber die Fehlerisolation nicht ersetzen. Liegt die Ursache in Dialplan, SIP-Berechtigungen, Firewall-Regeln, Codec-Aushandlung oder Medienrouting, kann ein Neustart das Problem nur kurz verdecken oder wirkungslos bleiben. Besser ist es, Symptome zu dokumentieren, Signalisierungstraces und Protokolle zu sichern und dann zu bestimmen, ob der erste Fehler im Endgerät, Netz oder in der Kommunikationsplattform liegt.
Becke Telcom kann die Fehlersuche auf Grundlage der tatsächlichen Architektur von Endgerät, IP PBX, SIP-Trunk, Netzwerkvermittlung, SBC und Leitstellensystem unterstützen. Becke Telcom bietet außerdem Ex-Telefone, Ex-Beschallungstelefone, SIP-Gateways, IP-Beschallung und integrierte Leitstellenausrüstung für petrochemische Anlagen, Energie, Bergbau, Tunnel und weitere industrielle Kommunikationsumgebungen.
