Startseite → VoIP-Wissen

VoIP: Einseitige Audio-Probleme systematisch eingrenzen

Redaktion: SpeedNetwork GmbH · 22. September 2026 · ca. 6 Minuten Lesezeit

Diagnosekette von SIP-Signalisierung über SDP-Abgleich zur RTP-Prüfung in beiden Richtungen

In diesem Ratgeber

Wenn ein Anruf klingelt und angenommen wird, aber nur eine Person die andere hört, sollten Sie Signalisierung und Medien getrennt untersuchen. Für einseitige Audio-Probleme ist „der Trunk ist registriert“ noch keine Diagnose. SIP nach RFC 3261 organisiert Sitzungen; RTP nach RFC 3550 transportiert Echtzeitmedien. Ein erfolgreicher SIP-Dialog beweist deshalb nicht, dass Sprachpakete beide Endpunkte erreichen und dort nutzbar sind.

So grenzen Sie einseitige Audio-Probleme ein

Vermeiden Sie Meldungen wie „Telefonie geht nicht“. Notieren Sie stattdessen die Perspektive: Teilnehmer A hört B, aber B hört A nicht. Ergänzen Sie Anrufrichtung, betroffene Nebenstelle, Gegenstelle, Uhrzeit mit Zeitzone und Phase. Trat der Fehler vor der Annahme, unmittelbar danach oder erst nach Halten und Vermitteln auf? Diese Angaben sind die Grundlage, um denselben Versuch in mehreren Protokollen wiederzufinden.

Legen Sie zunächst eine kleine Testmatrix an: ein- und ausgehend, internes und externes Ziel, betroffener und unauffälliger Arbeitsplatz. Nutzen Sie freigegebene Testanschlüsse und eine einfache Sprechprobe in beide Richtungen. Prüfen Sie außerdem Stummschaltung, Audiogerät und Lautstärke. Dokumentieren Sie jede Beobachtung ohne vorschnelle Ursachenzuordnung: „B empfängt keinen hörbaren Ton“ sagt noch nicht, an welchem Netzübergang die Störung liegt.

SIP-Aufbau und Medienbeschreibung auseinanderhalten

Verfolgen Sie zunächst INVITE, Antworten, Annahme und ACK für den betroffenen Aufbau. Fehlt die erwartete Signalisierung oder endet die Verbindung sofort wieder, bearbeiten Sie zunächst diesen Befund. Die SIP-Abläufe und Antwortklassen sind in RFC 3261 definiert. Halten Sie fest, ob ein SBC oder eine Telefonanlage getrennte Anrufabschnitte erzeugt; vergleichen Sie dann nicht versehentlich Nachrichten verschiedener Abschnitte.

Anschließend untersuchen Sie das tatsächlich ausgehandelte SDP. Nach RFC 8866 enthält es unter anderem Verbindungsinformationen und Medienbeschreibungen. Für Audio interessieren insbesondere die wirksame Adresse aus c=, der Port und das Transportprofil aus m=audio sowie Payload-Zuordnungen. Eine medienbezogene Verbindungsadresse kann die Angabe auf Sitzungsebene ersetzen. Lesen Sie deshalb nicht nur die erste gefundene IP-Adresse.

Prüfen Sie Angebot und Antwort gemeinsam. Die Richtungsattribute sendrecv, sendonly, recvonly und inactive beeinflussen die erwartete Medienrichtung; ein abgelehnter Medienstrom kann mit Port null erscheinen. Die Regeln dazu beschreibt RFC 3264, das SDP-Offer/Answer-Modell. Vergleichen Sie nach einem Re-INVITE erneut: Die Beschreibung beim ersten Aufbau muss nicht bis zum Gesprächsende unverändert gelten.

RTP in beiden Richtungen bis zur Fehlergrenze verfolgen

Erstellen Sie eine Skizze mit den tatsächlich beteiligten Medienknoten: Telefon, PBX, SBC, NAT-Gateway und Provider-Medienseite, soweit bekannt. Tragen Sie für jeden Abschnitt erwartete und beobachtete Quell- und Zieladressen samt Ports ein. Messen Sie möglichst gleichzeitig vor und hinter der vermuteten Fehlergrenze. Beschränken Sie die Untersuchung auf Systeme und Schnittstellen, für die Sie autorisiert sind.

  • Kein ausgehender Medienstrom am ersten Messpunkt: Audiogerät, Anwendung, ausgehandelte Richtung und lokale Medienverarbeitung untersuchen.
  • Pakete verlassen das Netz, kommen aber nicht zurück: Rückweg, Zieladresse, Freigaben und Gegenstellenbeobachtung abgleichen.
  • Pakete kommen am Gateway an, nicht am Endpunkt: Den internen Weiterleitungsweg und die konkrete NAT-Zuordnung prüfen.
  • Pakete erreichen beide Endpunkte: Codec-Zuordnung, Entschlüsselung und Wiedergabe untersuchen, statt weiter pauschal Ports zu öffnen.

RTP-Sequenznummern und RTCP-Berichte können Paketverluste und Empfangseigenschaften sichtbar machen; ihre Bedeutung beschreibt RFC 3550. Sie beweisen aber nicht allein, dass ein Mensch verständliche Sprache hört. Ein Paket kann beispielsweise ankommen, ohne im richtigen Audiogerät wiedergegeben zu werden. Ergänzen Sie deshalb Paketbelege um den kontrollierten Hörtest und vermeiden Sie Diagnosen nur anhand eines grünen Verbindungsstatus.

NAT und Asterisk gezielt statt pauschal korrigieren

Ein typischer Prüffall ist eine private Medienadresse, die für den vorgesehenen externen Empfänger nicht erreichbar ist. Private Adressen sind allerdings nicht automatisch falsch: In einem passenden internen oder getunnelten Pfad können sie richtig sein. Vergleichen Sie immer die konkrete Topologie. Die Asterisk-Anleitung für PJSIP hinter NAT trennt dafür lokale Netze, externe Signalisierungsadresse und externe Medienadresse.

Die dort erläuterten Optionen erfüllen unterschiedliche Aufgaben: rtp_symmetric richtet zurückgesendete Medien nach der empfangenen Quelladresse und dem Port aus. force_rport betrifft den Rückweg von SIP-Antworten, rewrite_contact die Behandlung von Kontaktadressen. Keine davon ist ein allgemeiner Ersatz für eine korrekte Firewall oder eine passende Netzarchitektur. Nutzen Sie die offizielle Beschreibung der NAT-Optionen für die eingesetzte Konfiguration, statt alle Schalter vorsorglich einzuschalten.

Prüfen Sie ebenfalls, ob direct_media einen direkten Medienpfad zwischen Endpunkten erlaubt. Dann kann der untersuchte PBX-Messpunkt am tatsächlichen Audioweg vorbeiliegen. Planen Sie Änderungen an Medienführung oder NAT in einem kontrollierten Wartungsfenster, sichern Sie die Ausgangskonfiguration und verändern Sie jeweils nur eine Hypothese. Für den Anschlusskontext finden Sie ergänzende Informationen zum Asterisk-SIP-Trunk.

Beispiel: Audio fällt erst nach Halten aus

In unserem fiktiven Test funktioniert Audio zunächst beidseitig. Nach Halten und Wiederaufnahme hört A nichts mehr. Statt den gesamten Trunk neu einzurichten, vergleichen Sie das letzte funktionierende SDP mit dem neuen Angebot und der Antwort. Prüfen Sie insbesondere, ob die Medienrichtung wieder passt und ob sich Adresse oder Port geändert haben. Das zugrunde liegende Änderungsmodell ist in RFC 3264 beschrieben.

Angenommen, der neue Zielport erscheint im SDP, am internen Messpunkt geht der Medienstrom jedoch noch zum alten Port. Damit haben Sie eine überprüfbare Abweichung zwischen Aushandlung und beobachtetem Verhalten, noch keine endgültige Herstellerdiagnose. Wiederholen Sie denselben Test nach einer gezielten Korrektur und protokollieren Sie beide Zustände. Falls dagegen schon das SDP unplausibel ist, beginnt die nächste Untersuchung bei dessen Erzeugung oder Veränderung.

Sicher diagnostizieren und belastbar eskalieren

Schalten Sie die Firewall für einen Funktionstest nicht vollständig ab. Prüfen Sie stattdessen die zur vereinbarten Topologie passenden Freigaben, protokollierte Verwerfungen und tatsächlich verwendeten Medienbereiche. Bei einem vermuteten SIP-ALG-Eingriff vergleichen Sie Nachrichten auf beiden Seiten des Geräts. Lassen Sie eine gezielte Änderung erst aus einem nachgewiesenen Befund folgen; behandeln Sie Sicherheitsfunktionen nicht als pauschale Störquelle.

Beschränken Sie Mitschnitte zeitlich und auf die nötigen Verbindungen. Behandeln Sie Rufnummern, SIP-Identitäten, Netzwerkadressen und Sprachinhalte als sensible Daten. Laden Sie Rohmitschnitte nicht in öffentliche Analyseportale oder frei zugängliche Tickets. Bevorzugen Sie redigierte Ablaufdiagramme und Zähler; übermitteln Sie notwendige Detaildaten nur über einen abgestimmten geschützten Kanal. Planen Sie Zugriff, Aufbewahrung und anschließende Löschung bereits vor der Aufzeichnung.

  1. Ein reproduzierbarer Testfall mit Uhrzeit, Richtung und betroffener Phase.
  2. Die lokale Anrufkennung und, falls erforderlich, die Zuordnung der Anrufabschnitte.
  3. Redigiertes SDP vor und nach dem Fehler sowie erwartete Medienziele.
  4. Paket- oder Zählerbefunde je Richtung und Messpunkt.
  5. Geprüfte Hypothesen, durchgeführte Änderung und Ergebnis des Wiederholungstests.

Häufige Fragen zu fehlendem VoIP-Audio

Warum reicht eine erfolgreiche Registrierung nicht aus?

Sie bestätigt nicht den Medienpfad eines späteren Gesprächs. Prüfen Sie den konkreten Anruf einschließlich SDP und RTP. Ein Registrierungsstatus kann die Suche unterstützen, ersetzt aber weder die richtungsbezogene Messung noch einen beidseitigen Hörtest.

Muss ich bei verschlüsseltem Audio die Verschlüsselung abschalten?

Nein. Beginnen Sie mit Metadaten, Paketfluss, Endpunktmeldungen und der Prüfung der vereinbarten Medienparameter. Ein produktiver Sicherheitsabbau ist kein notwendiger erster Diagnoseschritt. Wenn zusätzliche Untersuchungen nötig sind, planen Sie einen gesonderten autorisierten Test.

Was unterscheidet fehlendes Audio von langer Aufbauzeit?

Ordnen Sie die Wahrnehmung zuerst einer Gesprächsphase zu. Stille vor der Annahme ist nicht derselbe Befund wie fehlende Sprache nach der Annahme. Die Messgrenzen erläutert unser Beitrag zu ASR, ACD und PDD.

Mit klaren Befunden weiterarbeiten

Treten Probleme nur unter Last auf, ergänzen Sie die Prüfung um die Dimensionierung von CPS und Kanälen. Für eine technische Anfrage an SpeedNetwork genügt zunächst eine anonymisierte Fehlerbeschreibung mit Topologie und Testzeitpunkt. Übermitteln Sie keine vollständigen Sprachmitschnitte ungefragt.

Quellen und technische Vertiefung

Weiterführende Fachartikel

Dieser Beitrag wurde mit KI-Unterstützung erstellt. Technische Aussagen sind anhand der verlinkten Primärquellen nachvollziehbar. Eigene Beispiele sind als solche gekennzeichnet und keine zugesicherten Leistungswerte.