Summary

  • RFC 5140 fills a local registration gap: gateways send reachability to an Ingress Location Server, which may pass a transformed view into TRIP.
  • The gateway is Send Only. It advertises; it does not learn peer routes or choose the route used for a call.
  • TotalCircuitCapacity is an administratively provisioned upper bound, not a live reservation.
  • AvailableCircuits is a dynamic local observation and must not be propagated beyond the peer Location Server.
  • A positive availability value can be stale before the next call arrives.
  • CallSuccess is historical, windowed and based on a gateway-defined mapping of disconnect causes.
  • A busy or unavailable called party can conventionally count as success even when no conversation occurred.
  • CallSuccess is intended to improve probability, not certify the next call's outcome.
  • Consolidation unions routes for one destination; aggregation summarizes different destinations. Both alter the evidence surface.
  • The receiver implementation decides important details of consolidation, so constituent provenance must survive the projection.
  • IPsec can protect peer traffic without proving that a route, capacity report or success definition is correct.
  • Operators need separate receipts for registration, freshness, transformation, selection, signaling, PSTN disposition and business outcome.

A green route is still only an input

Imagine the routing proxy at the instant a call arrives. One gateway has advertised the destination. Its static capacity is high, its last dynamic report says circuits remain, and its historical success ratio looks better than its peers. Every visible signal points in the same direction. The proxy selects it.

Nothing in that decision proves what happens next.

The available-circuit count may have changed after the report. The success ratio may describe a different traffic mix. A call that reached Alerting but found the called party busy may have been classified as successful. The selected gateway may accept signaling and still fail further downstream. RFC 5140 is useful precisely because it gives the proxy more evidence. The error is to treat the evidence as the outcome it was meant to predict.

That distinction matters because TGREP sits at a seam. TRIP carries telephony routing information between providers, but does not say how an internal gateway injects routes or how a provider chooses a particular gateway. TGREP lets the gateway register its routes and selected resource attributes with an Ingress Location Server. The receiver can feed routing information to an Egress LS, which may disseminate it through TRIP. Selection and execution remain later acts.

The sender cannot see the whole decision

RFC 5140 makes the gateway asymmetric. It opens a TRIP-like peering session with its Send Receive Capability set to Send Only. It transmits UPDATEs containing its reachability and attributes. It does not maintain incoming or local route databases and does not run call-route selection.

If an UPDATE arrives while its finite-state machine is Established, the gateway silently discards the message and remains Established. A healthy session therefore proves neither that the gateway learned a route nor that it accepted a new operating instruction. The gateway's Adj-TRIB-GW-Out contains what it advertised to each peer LS; the RFC explicitly leaves population of that database outside scope and notes that manual configuration is possible.

An accountable system records where an advertised route came from before TGREP: provisioning system, operator action, gateway observation or another source. A protected UPDATE cannot repair an untraceable source database.

Capacity has two clocks

TotalCircuitCapacity and AvailableCircuits look related but describe different realities. Total capacity is the administratively provisioned ceiling. It changes infrequently and may be propagated beyond the receiving LS. Available circuits is a report of what remains at a point in time. It can change with every call, applies only between a gateway and its managing peer LS, is not aggregated and must not be disseminated.

RFC 5140 recommends reducing update load and using a sufficiently large window to produce a useful aggregate. That is an engineering trade-off, not an invisible detail. A smoother signal is easier to carry and less exact at the instant of action. A system that displays the latest number without its observation time, window and update policy hides the very uncertainty introduced to make the protocol scalable.

Even the static ceiling is conditional. Trunks can be removed for maintenance. Aggregated capacity may add values for routes to the same prefix inside one ITAD, but the sum does not prove that every component remains usable under one policy, congestion state or destination condition. Capacity should be stored as a claim with source and time, never as a reservation for a future call.

The success ratio contains a local theory of success

The most revealing attribute is CallSuccess. It carries two counters: calls considered successfully terminated and total attempted calls over the same window. More observations may improve statistical significance. Counter wrap forces alignment resets, and the receiver must sample frequently enough to avoid losing meaning.

But the numerator is not natural law. The gateway maps disconnect causes into success and failure. RFC 5140 says a call that reached Alerting but did not connect because the called party was unavailable or busy is conventionally successful. Resource or circuit unavailability is conventionally failure. The exact mapping remains at the reporting gateway's discretion.

That makes the ratio operationally valuable and semantically local. One gateway may optimize for reaching the destination network; another dashboard may imply human connection; a business process may care about completed service. Comparing ratios without the cause mapping, time window, denominator and traffic population compares labels, not outcomes.

The protocol is candid about the limit: the statistic may help select among alternatives to increase the probability of successful termination. It is not aggregated, it is not propagated, and it says nothing certain about the next call.

A receiver creates a new statement

The TGREP receiver can see routes from several gateways. Consolidation combines routes for the same destination so that collective capabilities are not lost. RFC 5140 illustrates a union of carrier values and a union of prefix lists. The exact treatment of different attributes and address families is left to implementations.

Aggregation is different. It combines different destinations into a summary according to TRIP rules, reducing routing information. The specified order is consolidation first, aggregation second.

After both operations, a candidate route can be a projection created by the receiver rather than any one gateway's original assertion. That is not a defect. It is why provenance matters. The projection should retain constituent gateway and session, original destination and attributes, transformation rule, excluded values, time and policy version. Without those receipts, a union can look like one gateway offered every capability simultaneously, while a summary can conceal destination-level variation.

Labels route calls; they do not authorize reality

TGREP can describe E.164 or routing-number prefixes, trunk groups and carriers. TrunkGroup and Carrier may also be used as flat address families, and a session must choose one of three categories rather than mixing prefix, trunk-group and carrier families. These rules make statements interoperable. They do not establish the gateway's commercial authority over a carrier, present control of a trunk or legal entitlement to terminate a number.

RFC 4904 standardizes trunk-group parameters in tel and SIP URIs. RFC 4694 defines number-portability parameters. Those formats preserve useful routing intent, but format compliance is not present resource control. The decision maker must verify the sender's configured scope separately.

Session security stops at semantic truth

RFC 5140 restates TRIP's IPsec model. AH or ESP can authenticate origin, preserve integrity, resist replay and, with ESP, provide confidentiality. That protects messages on the peer relationship.

It does not prove that a manually populated route is current, that a prefix belongs within the sender's operating scope, that the success mapping matches the buyer's objective or that the selected call completed. Cryptographic provenance answers who sent protected bytes under a security association. Accuracy, authority, freshness and outcome remain different questions.

The operational evidence chain should therefore remain explicit: gateway identity and authority; original UPDATE and observation time; measurement window and counter epoch; receiver validation and transformation; proxy policy and alternatives; signaling exchange; PSTN disposition; and, if the organization claims one, human or business outcome.

RFC 5140 improves the decision surface. It does not erase the distance between an advertisement and the world.

Sources

  1. RFC 5140, HTML
  2. RFC 5140, text
  3. RFC Editor record
  4. IETF Datatracker
  5. Document history
  6. RFC 5140 errata search
  7. IANA TRIP parameters
  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: IP Security Architecture
  14. RFC 4302: IP Authentication Header
  15. RFC 4303: IP Encapsulating Security Payload
  16. RFC 4306: IKEv2
  17. RFC 4835: ESP and 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