Zusammenfassung

  • Sprachkodierung kann robbed-bit- und Mehrfrequenzsignale zerstören; RFC 5244 bildet sie deshalb als definierte telephone-events für einen RTP-Trunk ab.
  • Der Empfang bestätigt eine Meldung an einer Grenze. Er bestätigt weder die Eingangserkennung noch den rekonstruierten Ausgang, die Reaktion der Altanlage, den Verbindungsaufbau oder die Buchung.

Der grüne Zähler am falschen Kontrollpunkt

Alle drei redundanten Meldungen sind angekommen. Die SRTP-Prüfung ist gültig. Kein Sequenzsprung ist sichtbar. Trotzdem baut die Gegenstelle die Verbindung nicht auf. Das ist kein Paradox, sondern eine falsch benannte Metrik.

Der RTP-Trunk überbrückt einen Abschnitt zwischen zwei Gateways. Im alten Netz liegen Signale in Tönen, elektrischen Zuständen oder niederwertigen Medienbits. Ein Sprachcodec kann diese Informationen tilgen. Das sendende Gateway erkennt sie deshalb vor der Kodierung und überträgt eine diskrete Ereignisbeschreibung.

Am anderen Ende beginnt eine neue Aufgabe: Version und Signalisierungsfamilie bestimmen, Kopien zusammenführen, Dauer und Ende deuten, lokale Bitvorgaben anwenden, Ton oder Zustand erzeugen und die Altanlage innerhalb ihres Zeitfensters erreichen. Erst danach kann diese Anlage ihren eigenen Zustand ändern.

Präzise Codes mit begrenzter Zuständigkeit

RFC 5244 beschreibt SS No. 5, R1/MF, R2, ABCD-Übergänge, Durchgangstöne, Trunk-Unverfügbarkeit und Gebührenimpulse. Zugleich warnt das Dokument, dass die Beschreibungen der Signalisierungssysteme unvollständig sind und wichtige Implementierungsdetails auslassen.

Die Ereignistabelle ist also eine Schnittstelle, keine vollständige Telefonie-Logik. Richtung, Gesprächsphase, vorheriger Zustand, Toleranzen und lokale Konfiguration bleiben außerhalb des Codes. Ein empfangenes Ereignis kann syntaktisch richtig und im aktuellen Kontext dennoch wirkungslos sein.

Auch die Versionsgeschichte ist Teil der Bedeutung. RFC 5244 korrigiert mehrdeutige, fehlerhafte oder redundante Zuordnungen aus RFC 2833. Vollständige Rückwärtskompatibilität besteht nur bei voller ABCD-Signalisierung. Ein Log ohne Definitionsversion verliert damit die semantische Herkunft.

Wiederholung ist kein mehrfacher Auftrag

ABCD-Zustandswechsel werden zur Robustheit dreifach gesendet und später aufgefrischt. Gebührenimpulse sollen ebenfalls wiederholt werden. RFC 4733 erlaubt mehrere Pakete für dasselbe Ereignis und definiert Zeitstempel, Dauer und Endemarkierung.

Der Empfänger muss daraus genau eine wirksame Instanz bilden. Sonst macht die Verlusttoleranz aus einem Übergang mehrere Übergänge. Im Abrechnungspfad wäre ein Zählen der Pakete besonders fatal: Wiederholung ist kein zweiter Gebührenimpuls im wirtschaftlichen Sinn.

Ein belastbarer Nachweis enthält deshalb Ereignisidentität, Kopienmenge, Deduplizierungsentscheidung, Anrufkorrelation und die Bestätigung des Systems, das die irreversible Wirkung besitzt.

Der vollständige ABCD-Ausgang entsteht lokal

ABCD-Ereignisse bezeichnen sich gegenseitig ausschließende Zustände; der jüngste Übergang bestimmt den gemeldeten Zustand. Werden nur A oder A/B genutzt, ergänzt das empfangende Gateway die ungenutzten Bits anhand seiner lokalen Konfiguration.

Damit kann kein Eingangsprotokoll allein beweisen, welcher vollständige Leitungszustand ausgegeben wurde. Dafür braucht es einen zweiten Messpunkt hinter der Rekonstruktion. Unterschiedliche Profile können aus demselben Paket unterschiedliche vollständige Werte erzeugen.

Zustände altern außerdem. Läuft ein Soft-State-Zeitraum ohne Auffrischung ab, kann der Wert unbekannt werden. Wer den letzten grünen Wert unbegrenzt hält, verwechselt gespeicherte Vergangenheit mit gegenwärtiger Verfügbarkeit.

Durchgang ist eine Rückwegentscheidung

Bei der Durchgangsprüfung sendet die initiierende Vermittlung einen Prüfton, die entfernte Seite richtet eine Schleife oder Antwort ein, und die initiierende Seite erkennt den Rücklauf. Das Ereignis für den Hinweg ist nicht die bestandene Prüfung. Auch die Meldung des Antworttons ist noch nicht die Entscheidung am Messpunkt.

Eine Paketaufzeichnung kann beide Codes zeigen, ohne Schleifenwirkung, Toleranzfenster oder Endurteil zu enthalten. „Töne übertragen“ und „Medienweg durchgängig“ bleiben zwei Aussagen.

Unter Last muss der Empfänger zudem abwägen. Ein zu frühes Abbrechen kann den Aufbau scheitern lassen; verlängertes Ausspielen erhöht die Aufbauzeit. Für eng getaktete Registersignale zählt die im Signalisierungsstandard vorgegebene Sequenz mehr als eine mechanische Kopie gemeldeter Dauern.

Unverfügbar benennt keinen Grund

Das Trunk-unavailable-Ereignis synchronisiert einen Zustand mit geringem Datenverkehr. RFC 5244 nennt Ausfall und administrative Maßnahme als mögliche Ursachen. Der Code ist somit kein Hardwarediagnosebericht.

Automatisierung benötigt zusätzlich Ursache, Gültigkeit und eine Bestätigung, dass Routing oder Inventar den Trunk tatsächlich entzogen haben. Ebenso beweist ausbleibende Auffrischung keine Wiederherstellung.

Kryptografische Herkunft ist nicht betriebliche Befugnis

Weil die Ereignisse Aufbau, Abrechnung und Abbau beeinflussen, behandelt RFC 5244 Abhören, unbefugte Verbindungen, Übernahme und Dienstverweigerung. Bei Schutzbedarf soll SRTP mit automatisiertem Schlüsselmanagement eingesetzt werden.

Das stärkt Herkunft und Integrität der Meldung. Es beweist nicht die Richtigkeit des Detektors oder die geschäftliche Befugnis, einen Gebühreneintrag auszulösen. Authentisierung, Autorisierung und Wirkungsnachweis müssen getrennt bleiben.

Sieben Belege statt eines Sammelstatus

Erforderlich sind eigene Belege für Erkennung, Code samt Version, authentisierte Zustellung, Dekodierung und Deduplizierung, Rekonstruktion, Annahme durch die Altanlage und Gesprächs- oder Geschäftsergebnis. Eine Korrelations-ID verbindet sie, ohne Lücken zu erfinden.

Das entspricht Lu Hengs Wirklichkeitsprinzip. Der Standard beschreibt die Sollform. Der Betrieb muss zeigen, was erkannt und verändert wurde. Ein ehrliches „unbekannt“ ist wertvoller als ein transitive Erfolgsmeldung.

Sources