Summary

  • RFC 3015 modelled a Context as a Media Gateway's local association of Terminations, complete with topology, modes, commands and scoped identifiers; it did not define that object as a universal call record.
  • Transaction ordering, audits and at-most-once retry memory established narrower execution facts. None proved external-path delivery, remote playout or that two people had communicated.

Imagine a controller asking a gateway to associate an RTP stream with a circuit. The gateway accepts an Add, assigns the new local object an identifier and returns success. On an operations screen, the Context is now “connected.” Every word in that sentence can be true while the far party hears silence.

That gap is not a defect in the name. It is the boundary RFC 3015 made visible. Published in November 2000 as Megaco Protocol Version 1.0, and issued as common text with ITU-T H.248, the specification controlled the parts of a physically decomposed multimedia gateway that belonged to media connection control. It did not make the control protocol a witness to every network, endpoint and human event beyond the gateway.

The object lived inside one gateway

The connection model began with two abstractions. A Termination sourced or sank one or more media or control streams. A Context associated Terminations and described their topology—who heard or saw whom—and, for larger groups, their mixing or switching behavior.

That vocabulary was deliberately local. The Media Gateway assigned each ContextID, and the value was unique within that gateway. A Context could represent part of a two-party call, a conference arrangement, a waiting call or another media association. It was not a globally durable identity for “the call,” a subscriber, a billing event or a human exchange.

The lifetimes made the distinction concrete. Physical Terminations, such as provisioned circuit channels, could exist for a long time. Ephemeral Terminations, such as representations of RTP flows, normally existed only for their use. The null Context held physical Terminations not associated with another Termination. Add could create an active Context implicitly; Subtract could return a physical Termination to the null Context or destroy an ephemeral one; Move could relocate a Termination. When the last Termination left, the Context disappeared automatically.

A record that appears and vanishes as a consequence of local commands is valuable operational state. It is not a permanent transcript of everything that happened to the service.

Topology and boundary mode answered different questions

RFC 3015 separated the topology within a Context from the mode of a Termination. Topology described media relations among Terminations: both-way, one-way or isolated paths among the objects held by the MG. Mode described flow at the gateway's ingress or egress.

This matters because “T1 can hear T2” in the gateway model is a programmed association, not a microphone report from a remote listener. The gateway can correctly switch an incoming circuit toward an outgoing packet stream while packets are later dropped, delivered to the wrong remote socket, rejected, decoded badly, muted or never rendered. Conversely, an audit may observe a local mode without reconstructing which external packets arrived during the interval.

The Context therefore occupied one reality layer: realised connection state at one controlled device. Session descriptions, transport addresses, RTP sequence and reception evidence, endpoint rendering and human understanding belonged to later layers with different custodians.

A transaction was not the whole conversation

Commands were nested inside Actions, and Actions inside Transactions. An Action normally addressed one Context. Commands inside the same transaction executed in order. That gave the controller a way to request a coherent local change and receive results for commands that succeeded or an error where processing failed.

Across different transactions, however, ordering was not automatic. The specification told controllers that wanted consistent operation to impose discipline. For one Termination there should normally be at most one outstanding Add, Modify or Move, unless the commands shared a transaction. Subtract could intervene. A wildcarded removal could step ahead of pending additions, obliging the controller to clean up the stragglers and delay new additions until the removal was acknowledged.

The essential ownership was clear: the MG executed commands; the MGC owned the sequence of intentions. A successful reply established what the gateway reported about that transaction. It did not prove that a second controller shared the same desired state or that future transactions would preserve the association.

TransactionPending was narrower still. It said that processing remained active and incomplete. It restarted a requester's timer; it did not predict success, reserve an end-to-end path or attest to media flow.

Auditing did not freeze time

Megaco supplied two useful but different queries. AuditValue returned current property, event, signal and statistic values. AuditCapabilities returned possible values. Capability was not present state, and present state was not outcome.

Wildcarding added another limit. A response could contain a union across matching Terminations. That reduced traffic, but a union did not show which member supplied which possible value. The answer remained evidence about the requested scope, not a complete per-object history.

Most importantly, RFC 3015 said that AuditValue and AuditCapabilities were not subject to command sequencing. An audit taken while mutations were in flight required a time and ordering context. A value could be accurate at the instant the MG observed it yet stale relative to the controller's next decision. Calling the response “current” did not make it a linearizable snapshot of every related transaction.

Subtract offered statistics collected during a Termination's participation in a Context. Those figures could help reconstruct local use before the association disappeared. They still reported from the gateway's side. A byte or packet count there did not establish remote receipt, intelligible playout or a completed human exchange.

At-most-once protected a command boundary

UDP could lose requests or replies. Repeating most Megaco commands without protection was unsafe because many were not idempotent: executing an Add twice could make gateway state unpredictable. RFC 3015 therefore required at-most-once behavior.

Peers kept recent replies and currently executing transactions. They compared a transaction identifier, scoped with the sender identity, against that memory. A completed duplicate received the remembered response; an in-progress duplicate was not executed again and could receive TransactionPending. Response acknowledgements allowed stored replies to be released while identifiers remained long enough to discard delayed duplicates.

The guarantee had a stated custody boundary. It depended on retained memory, identifier uniqueness, LONG-TIMER and the current operating epoch. After expiry or restart, the old evidence did not speak forever. Even when it worked perfectly, at-most-once meant “this gateway transaction was not re-executed within the protocol's comparison window.” It did not mean “the call happened exactly once.”

TCP did not abolish the distinction. RFC 3015 observed that transaction requests or responses could still be lost around failures and recommended application-level handling. A reliable byte stream could carry a command; it could not preserve the gateway's lost process memory or certify downstream media.

Security guarded authority, not outcome

Unauthorized Megaco commands could establish or disrupt calls, so the RFC required protection of the control connection in IP environments and specified IPsec. Origin authentication, integrity, anti-replay and confidentiality protected the instruction channel. They did not convert the controller into the remote listener, or the authenticated request into proof that the service worked.

The standards history reinforces the limited claim. RFC 3015 met the architecture requirements in RFC 2805 and was later obsoleted by RFC 3525. RFC 3435 placed MGCP on a separate Informational line and pointed toward Megaco/H.248 as the standards-based approach. Those records explain the protocol family. They do not tell us which product deployed which edition, whether two vendors interoperated or how many calls succeeded.

The durable achievement was sharper than a “connected” badge. Megaco gave control software a common way to name a local association, program it, inspect it, order changes within a transaction and contain duplicate commands. It also left enough boundaries visible to resist a larger claim. A Context could be connected without proving the call.

Sources