Zusammenfassung

  • TGREP registriert Gateway-Routen beim Location Server eines Telefoniedomains.
  • Das Gateway sendet ausschließlich und führt selbst keine Routenauswahl durch.
  • Wie seine Ausgangsdatenbank befüllt wird, liegt außerhalb der RFC und kann manuell sein.
  • TotalCircuitCapacity ist eine provisionierte Obergrenze, keine Reservierung.
  • AvailableCircuits ist eine dynamische lokale Beobachtung und darf nicht weitergegeben werden.
  • Größere Meldefenster entlasten das Protokoll, vergrößern aber den Abstand zum Entscheidungszeitpunkt.
  • CallSuccess zählt vergangene Versuche und lokal als erfolgreich klassifizierte Beendigungen.
  • Ein Ruf bis Alerting mit besetztem Teilnehmer kann konventionell als Erfolg gelten.
  • Die genaue Zuordnung der Disconnect Causes bleibt dem meldenden Gateway überlassen.
  • Consolidation verbindet Routen desselben Ziels; Aggregation fasst unterschiedliche Ziele zusammen.
  • IPsec schützt Peer-Nachrichten, nicht die sachliche Richtigkeit ihrer Attribute.
  • Registrierung, Messung, Transformation, Auswahl, Signalisierung und Ergebnis benötigen getrennte Belege.

Eine gute Rangfolge ist noch kein guter Ausgang

Der Proxy besitzt drei Kandidaten. Einer meldet mehr freie Leitungen, einer die größte Gesamtkapazität, einer die beste historische Erfolgsquote. Eine Policy gewichtet die Werte und entscheidet sich für eine Route. Bis hierhin kann alles korrekt sein.

Der letzte freie Circuit kann inzwischen belegt sein. Die Quote kann einen anderen Zeitraum oder eine andere Definition von Erfolg enthalten. Nach der Auswahl können Signalisierung, PSTN-Zustand oder Teilnehmerverhalten den Ausgang verändern. RFC 5140 standardisiert die Eingaben in die Auswahl, nicht den Ausgang hinter ihr.

TRIP verteilt Telefonie-Routen zwischen Providern, regelte aber weder die interne Einspeisung durch Gateways noch die Wahl eines konkreten Gateways. TGREP schließt diese lokale Lücke. Ein Sender auf dem Gateway liefert Reachability an den Ingress LS. Dieser kann die Information bearbeiten, an den Egress LS übergeben und damit TRIP speisen. Jede Stufe hat eine andere Sicht und Verantwortung.

Das Gateway sendet, lernt aber nicht

Beim Verbindungsaufbau setzt das Gateway seine Send Receive Capability auf Send Only. Es sendet seine gesamte Reichweite und zugehörige Attribute per UPDATE. Es besitzt keine Entsprechung zu Adj-TRIBs-In oder Loc-TRIB, lernt keine fremden Routen und führt weder Auswahl noch Aggregation aus.

Erhält es im Zustand Established ein UPDATE, verwirft es die Nachricht still und bleibt Established. Ein aktiver Session-Status belegt deshalb nicht, dass das Gateway eine Anweisung des LS übernommen hat.

Für jeden Peer gibt es ein Adj-TRIB-GW-Out. Wie es befüllt wird, lässt RFC 5140 offen; manuelle Konfiguration ist ausdrücklich möglich. Die Provenienz muss daher vor dem geschützten Paket beginnen: Quelle der Konfiguration, berechtigte Person oder Maschine, Zielumfang, Änderungszeit und Rückzugsbedingung.

Zwei Kapazitätsfelder, zwei Beweisräume

TotalCircuitCapacity beschreibt die administrativ bereitgestellte Gesamtzahl möglicher gleichzeitiger Rufe. Sie ist relativ statisch, kann sich etwa durch Wartung an Trunks ändern und darf weiterverbreitet werden. In bestimmten Aggregationen innerhalb desselben ITAD können Werte für dasselbe Präfix addiert werden.

AvailableCircuits meldet dagegen den beobachteten Restbestand einer Route. Er kann sich mit jedem Ruf ändern, dient der Auswahl pro Ruf, wird nicht aggregiert und darf den zuständigen Peer LS nicht verlassen.

Die RFC empfiehlt, UPDATE-Last zu begrenzen und ein ausreichend großes Fenster zu verwenden. Ein ruhigerer Wert ist betrieblich nützlich, aber weniger unmittelbar. Ohne Beobachtungszeit, Fenster, Meldeschwelle und seitdem eingetroffene Rufe wird eine Stichprobe als Bestand missverstanden.

Auch die Gesamtkapazität ist nur eine mögliche Obergrenze. Eine Summe beweist weder gemeinsame Fehlerfreiheit noch Austauschbarkeit unter derselben Policy. Provisionierter Deckel, beobachteter Rest und reservierte Ressource sind drei verschiedene Zustände.

Der Zähler enthält eine lokale Erfolgslehre

CallSuccess besteht aus zwei Zählern über dasselbe Fenster: erfolgreich beendete und insgesamt versuchte Rufe. Mehr Versuche können die Statistik aussagekräftiger machen. Beim Überlauf des Versuchszählers wird der Erfolgszähler zur Ausrichtung zurückgesetzt; der Receiver muss häufig genug lesen.

Was in den Zähler gelangt, entscheidet das Gateway anhand des Disconnect Cause. Erreicht ein Ruf Alerting, wird aber wegen Abwesenheit oder Besetzt nicht verbunden, gilt er konventionell als erfolgreich. Scheitert er wegen fehlender Leitung oder Ressource, gilt er konventionell als fehlgeschlagen. Die genaue Abbildung bleibt im Ermessen des Gateways.

Damit ist die Quote eine nützliche lokale Betriebsgröße, keine universelle Gesprächsmetrik. Vor einem Vergleich müssen Cause-Mapping, Fenster, Nenner, Zählerepoche und Traffic-Mix übereinstimmen. Sonst werden Namen geordnet, nicht Ergebnisse.

Die Spezifikation verspricht nur eine höhere Wahrscheinlichkeit erfolgreicher Terminierung bei der Alternativenwahl. Das Attribut wird weder aggregiert noch verbreitet und kennt den nächsten Ruf nicht.

Der Receiver erzeugt eine Projektion

Mehrere Gateways können dasselbe Ziel ankündigen. Consolidation kombiniert diese Routen, damit kollektive Fähigkeiten nicht verloren gehen. Die RFC vereinigt beispielhaft Carrier-Werte und Präfixlisten. Die konkrete Behandlung verschiedener Attribute und Address Families überlässt sie der Implementierung.

Aggregation folgt danach und reduziert andere Ziele auf eine Zusammenfassung nach TRIP-Regeln. Die Reihenfolge zeigt, dass zwei verschiedene Transformationen stattfinden.

Die Route am Egress LS kann somit eine Aussage des Receivers sein, die kein einzelnes Gateway gesendet hat. Sie braucht eine rückverfolgbare Struktur aus Gateway, Session, Originalroute, Attributen, Zeit, Regel, Ausschlüssen und Version. Sonst wirkt kollektive Fähigkeit wie ein gleichzeitiges Versprechen eines einzigen Gateways.

E.164- und Routing-Präfixe, TrunkGroup und Carrier strukturieren Ziele und Präferenzen. Pro Session dürfen die drei Family-Kategorien nicht vermischt werden. RFC 4904 und RFC 4694 stabilisieren angrenzende Syntax. Korrekte Syntax belegt weder aktuelle Kontrolle über einen Trunk noch kommerzielle Vertretungsmacht oder physische Verfügbarkeit.

Peer-Sicherheit endet vor der Semantik

RFC 5140 übernimmt den IPsec-Ansatz von TRIP. AH oder ESP können Ursprung, Integrität und Replay-Schutz bereitstellen; ESP zusätzlich Vertraulichkeit. Damit sind Bytes zwischen konfigurierten Peers geschützt.

Eine manuelle Route wird dadurch nicht aktuell, ein alter Kapazitätswert nicht frisch, ein Cause-Mapping nicht objektiv und ein Sender nicht automatisch zum Vertreter eines Carrier. Der belastbare Nachweis verbindet Identität und Umfang, Original-UPDATE, Messzeit, Fenster und Epoche, Receiver-Transformation, Proxy-Policy und Alternativen, Signalisierung, PSTN-Disposition und behauptetes Geschäftsergebnis.

TGREP kann begründen, warum eine Route gewählt wurde. Was anschließend geschah, muss anschließend beobachtet werden.

Quellen

  1. RFC 5140, HTML
  2. RFC 5140, Text
  3. RFC-Editor-Eintrag
  4. IETF Datatracker
  5. Dokumenthistorie
  6. Errata-Suche zu RFC 5140
  7. IANA-TRIP-Parameter
  8. RFC 2871: Telephony Routing Framework
  9. RFC 3219: TRIP
  10. RFC 3261: SIP
  11. RFC 4904: Trunk Groups in tel/SIP-URIs
  12. RFC 4694: Number Portability Parameters
  13. RFC 4301: IPsec Architecture
  14. RFC 4302: AH
  15. RFC 4303: ESP
  16. RFC 4306: IKEv2
  17. RFC 4835: ESP/AH Algorithm Requirements
  18. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  19. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  20. Running-Code Primacy