Summary
- RFC 3435 assigned every endpoint one current
NotifiedEntity, but that value selected where gateway-originated commands travelled; responses still followed the source of each command, and commands could arrive from another source. - Backup takeover changed a routing association without supplying inter-Call-Agent conflict resolution, complete state transfer or proof of uninterrupted media. Audit, clearing, reachability, authority and user outcome remained separate receipts.
One pointer, several kinds of truth
Consider a hypothetical access gateway whose controller stops answering. A backup reaches the endpoint and supplies a new NotifiedEntity. The gateway now knows where to send its next notification. That is useful. It is also much less than a completed handover.
The backup may not know every connection decision the failed controller made. The old controller may recover with a different view. A response can return to the network source of a newly arrived command even though gateway-originated commands are pointed elsewhere. Media may still be flowing, already broken, or about to be cleared. The routing pointer answers one question while leaving the others open.
That boundary sits inside RFC 3435, the January 2003 revision of Media Gateway Control Protocol 1.0. The plain-text edition, RFC Editor record, Datatracker page, document history, reference graph and errata record establish the documentary record. They do not show that a named network implemented the mechanism or survived a measured failure.
A protocol for a decomposed gateway
MGCP divided the system. The Call Agent contained call-control intelligence; the media gateway handled media functions and exposed endpoints. The controller could request connections, modify their parameters, delete them, ask endpoints to observe events, generate signals and report service changes. Audit commands let it inspect endpoint and connection state.
RFC 2705, which RFC 3435 obsoleted, already described this master-and-gateway arrangement and assumed Call Agents would synchronize with one another. It did not define that synchronization. RFC 2805 recorded the broader IETF requirements for media-gateway control, including assurance, recovery and reconciliation. RFC 3015 documented the Megaco/H.248 standards-track architecture that RFC 3435's IESG note directed implementers to consider.
Those neighbouring documents matter because RFC 3435 was Informational. Its detailed requirements govern the protocol it describes; they are not evidence of IETF-standard status, universal deployment or successful calls. This article therefore follows one internal control surface rather than converting protocol vocabulary into market history.
What the notified entity actually did
RFC 3435 says each endpoint has one and only one Call Agent associated with it at a given time. The current value of the notified entity represents that association and determines where the gateway sends its commands. A NotifiedEntity parameter supplied by a Call Agent changes the endpoint's stored value.
If no explicit value has ever arrived, a provisioned default applies. If the value is empty and no default exists—a configuration the RFC strongly discourages—the source address of the last non-audit command becomes the destination. Audit traffic alone cannot silently seize the pointer.
The precision is important. The notified entity is the addressable recipient for gateway-originated protocol traffic. It is not a cryptographic certificate of authority. It is not a complete call-state ledger. It is not proof that every platform behind a DNS name shares current memory. It is not evidence that packets crossed the media plane.
The reply could go somewhere else
Responses follow a different rule. RFC 3435 sends a response to the source address of the command that caused it, regardless of the current notified entity. A Notify piggybacked with that response follows the same datagram destination. Elsewhere, the RFC says commands received by the gateway may come from any source.
This produces three facts that a log must not flatten. First, the endpoint has a current destination for its own commands. Second, a particular command arrived from a particular source. Third, the gateway returned a response to that source. None of those facts, alone, proves that the source was the uniquely authorized controller or that competing Call Agents agreed on the transition.
The requirement vocabulary of RFC 2119 and the grammar conventions of RFC 2234 make message behaviour precise. Precision at the wire level does not manufacture missing institutional or distributed-state evidence.
DNS offered reachability, not shared memory
Call Agents were named by domain name and optional port rather than one fixed network address. One name could resolve to several interfaces or several physical systems acting as a logical controller. The gateway should prefer an address already associated with a current request and try alternatives when contact fails. Failover must not depend on DNS answer order.
This was a practical indirection layer. It allowed a stable logical name to survive interface changes and let a gateway search alternative addresses. But resolving two addresses does not demonstrate that the machines hold identical connection records, saw the same notification sequence or apply the same authority policy. DNS says where packets may be sent; state replication requires its own receipt.
The missing handover arbiter
When an entire Call Agent remained unreachable, affected endpoints eventually became disconnected. A backup Call Agent could contact them with a new notified entity. RFC 3435 assumed that the failed and backup controllers would communicate and synchronize when returning control, or would swap primary and backup roles.
Then the document stated the unhidden limit: conflict resolution for handover between separate Call Agents was not in place. The protocol relied on the controllers knowing what they were doing and communicating with each other. AuditEndpoint could disclose the current notified entity, but a read of the present pointer could not reconstruct every prior decision or decide which controller had the legitimate claim.
The difference is the article's historical center. A system can have a single current field without having distributed consensus about how that field changed. “Last value stored” is an observation. “Rightful controller” is an authority conclusion. “Same call survived” is an operational outcome. RFC 3435 did not pretend those sentences were synonyms.
Disconnection created a choice, not a verdict
MGCP did not call an endpoint disconnected after one lost datagram. It used retransmissions, exponential backoff, alternative addresses, DNS refresh and bounded timers. T-MAX limited retransmission; beyond twice T-HIST, the endpoint entered disconnected state. Randomized delays reduced the risk that many endpoints would announce recovery simultaneously.
The first non-audit exchange after disconnection had to carry the disconnected fact. Once the Call Agent learned it, the RFC offered examples of what the controller might do: audit the endpoint or clear all its connections. Those actions were not equivalent. Audit attempted reconciliation from protocol-visible state. Clearing chose convergence by destruction.
Neither path guaranteed that media had continued. A successful RestartInProgress exchange proved a protocol transaction completed. It did not prove that an active conversation was audible, that no state disappeared, or that a subscriber experienced no interruption. RFC 3661 later clarified return-code use, but a better-defined result code still has the scope of that result code.
Later packages narrowed particular gaps
RFC 3991 defined an MGCP redirect and reset package. RFC 3992 defined lockstep state reporting for a bounded class of notification interactions. They show that operators and designers needed more explicit mechanisms around redirection and state. They do not retroactively turn the base notified-entity field into a controller-election or replicated-state protocol.
The IANA MGCP package registry and LocalConnectionOptions registry preserve the protocol's allocated vocabulary. Registration demonstrates coordinated names and references, not running implementations, correct synchronization or service continuity.
The durable lesson
RFC 3435 is valuable because it exposes how many layers hide behind the word failover. A destination can change. An alternative address can respond. A controller can receive a disconnected notice. An audit can return state. A clearing command can succeed. Media can still fail, and two controllers can still disagree.
Heng Lu's later account of reality layers supplies a useful analytical discipline: do not let the visible pointer borrow authority from evidence it does not contain. His argument for running-code primacy keeps the operational receipt separate from the standard's design. The minimum-initial-specification lens explains why a bounded pointer can coordinate action while leaving future conflict resolution outside the common core. These are retrospective editorial applications, not claims about the RFC authors' intent.
The notified entity was necessary because the gateway needed somewhere to send the next command. It was insufficient because continuity required more than an address. The protocol preserved that distinction in its text. History should preserve it too.
Sources
- RFC 3435 — HTML
- RFC 3435 — plain text
- RFC Editor information record
- IETF Datatracker document
- IETF Datatracker history
- IETF Datatracker references
- RFC 3435 errata
- RFC 2705
- RFC 2805
- RFC 3015
- RFC 3661
- RFC 3991
- RFC 3992
- RFC 2119
- RFC 2234
- IANA MGCP package registry
- IANA MGCP LocalConnectionOptions registry
- Heng Lu — reality layers
- Heng Lu — running-code primacy
- Heng Lu — minimum initial specification
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
