Summary
- RFC 3149 let a remote MGCP Call Agent interpret numbered feature keys, set key labels and lights, force hook state, and drive an XML display, but a key event remained distinct from the feature mapping and the resulting call state.
- Because display state could diverge from phone signaling state, the RFC gave the display a separate
disp/endpoint and routed key presses through the XML layer before the ordinary phone layer. - Ringing, handset and speaker volume, immediate handset/speaker switching, and microphone mute plus its indicator stayed local, showing that external call intelligence did not erase the endpoint's physical control surface.
The button reported a number, not a business meaning
The Media Gateway Control Protocol began from a strong architectural choice: call-control intelligence lived outside the gateway. A Media Gateway Controller, commonly called a Call Agent, told gateways what signals to produce and which events to report. The basic analog-line packages could support ordinary audio connection and signaling. A business phone, however, carried a more complicated surface—hold, transfer, redial, conference, message lights, programmable keys, an LCD, soft keys, a speaker and a mute control.
RFC 3149 extended MGCP with three package families. The Feature Key package described non-DTMF keys and their indicators and labels. The Business Phone package supplied force-off-hook, force-on-hook and beep signals. The Display XML package carried a small interface between the Call Agent and the screen.
The feature-key event was deliberately low level. The phone could say that key number 1 had been pressed. The Call Agent retained the programming that made key 1 mean hold, transfer, a line appearance or something else. Another model might map hold to key 23 or not expose that key at all. The same physical gesture therefore had no universal business meaning on the wire.
That separation matters for evidence. A valid notification proves that an endpoint reported a numbered key under a requested event set. To say “the user pressed hold” requires the mapping active at that time. To say “the call was held” requires the Call Agent's decision, the requested signals, the signaling transition and an observable media result. A dashboard that stores only button=hold has silently collapsed all of them.
Labels and lamps were outputs, not proof
The Call Agent could request a key-state signal, turning an indicator on or off, and could set free-form text beside a key when the phone had a suitable display. Those capabilities made a generic endpoint look like a business telephone whose functions could change with an application.
They also created a seam between presentation and operation. A label reading “Hold” could remain after the mapping changed. A lamp could be lit because a signal was accepted while the intended call feature failed. A key could report correctly while a user read another label or pressed a neighboring physical control. Rendering is an action with its own success criteria.
RFC 3149 pursued a minimum set of low-level events and signals. It explicitly tried to avoid excessive or redundant traffic: a Call Agent that only cared about the fact of a press did not need both press and release reports. That economy preserved a narrow wire interface. It also meant the protocol record was not a full account of human interaction. Debounce, physical placement, local timing and what the user saw required other observations.
The proper receipt therefore joins without merging: phone model, active key map, reported number, request and notification transaction, label and light state, Call Agent branch, signaling outcome, media outcome and user-visible state.
The display became another endpoint
The display was not merely decoration on the phone's signaling machine. RFC 3149 said its state could be asynchronous from signaling state and therefore expected it to have a distinct MGCP endpoint name, formed by prefixing the phone endpoint with disp/.
The example is revealing. A call arrives and rings while the display offers an option to redirect it immediately to voice mail. Selecting the option produces an XML post and can cancel ringing timeouts. Several clocks coexist: the screen may show the option, the user may select it, an event may reach the Call Agent, the timeout may be cancelled, signaling may change and the far end may experience a redirect. No single receipt proves the whole chain.
The XML package let the Call Agent point to a deck and card, supply substitution values and receive input or selection. Cards could contain text, lists, input boxes, timers and navigation. When a key served both the display script and ordinary phone behavior, the XML layer saw it first. It either consumed the key or passed it to the phone layer.
Priority in dispatch was not authority over reality. A script consuming a digit proved a local routing choice. It did not prove that the screen had rendered the intended card, that the posted value reached the correct controller or that signaling followed. The separate endpoint made asynchronous state addressable; it did not make that state automatically consistent.
Make and model stood in for exhaustive discovery
The Call Agent needed to know which keys and display capabilities a phone offered. The RFC considered exhaustive discovery possible but chose a simpler experimental parameter, X-UA, which asked for a string uniquely identifying make and model. The controller could use that identity to select a capability profile.
This was economical metadata, not a hardware attestation. A make/model string could be unsupported and ignored, stale relative to firmware, misconfigured or mapped to an incomplete profile. It did not prove the physical keyboard, display dimensions, indicator wiring or functioning audio hardware.
The X prefix also marked a compatibility boundary. A gateway unable to support the experimental parameter was expected to ignore it rather than reject the entire interaction. Absence of an answer meant uncertainty, not a default phone layout. A robust controller needed a bounded fallback instead of inventing capabilities.
The evidence ladder keeps the returned string, firmware and inventory identity beside the capability profile version and an observation of the actual surface. Model classification can select behavior; running hardware can appeal.
The user's hand retained immediate authority
Section 4 draws the sharpest line in the memo. Ringing, handset and speaker volume should be implemented locally. If a speaker phone is active, a user should be able to lift the handset and switch to it, then return to speaker mode, without any interaction with the Call Agent. The microphone mute button and its optional light should also be local.
This did not contradict the external-intelligence model. It specified its limit. The Call Agent interpreted features whose meaning belonged to call applications. The endpoint retained actions where a physical user needed immediate, device-bound control. The architecture centralized semantics while leaving some execution at the edge.
It would be tempting to fill in motives the RFC did not state: latency, failover, privacy, safety. Those may be plausible design benefits, but the document does not report measurements or a complete resilience theory. The supportable claim is narrower: these functions were assigned locally, and handset/speaker switching was expressly required not to involve the controller.
Even local control needed layered evidence. A mute button press is not the mute state; the lamp is not audio suppression; a locally changed audio path is not proof that the remote party heard the intended source. Physical input, local state, indicator and media result remain distinct.
Remote commands still met local resistance
The Business Phone package could force a speaker phone off-hook, force it on-hook or play a beep. These signals supported application integration, including initiating a call from a computer-selected number. Yet the specification said the user could negate forced off-hook by hanging up.
The detail prevents a simplistic controller story. A remote request was not the final state. The gateway interpreted the signal, physical hardware changed, and the user retained a local counteraction. The wire command, gateway acceptance, hook state, call setup and user action belonged to different clocks.
This is also where security language needs discipline. RFC 3149 said it introduced no new considerations beyond base MGCP. That did not say remote XML, key mappings or hook signals were intrinsically secure. Authentication, authorization, integrity and confidentiality depended on the base protocol and deployment. Password-mode input masked characters on the display; it did not certify encrypted transport or safe processing by the Call Agent.
The IESG note imposed another boundary. RFC 3149 documented a non-IETF protocol in use while Megaco/H.248 occupied the same problem space on the Standards Track. That status fact does not erase the operational design, prove universal migration or let a later specification rewrite what a phone actually did.
Intelligence was divided by consequence
The lasting lesson is not that local is always better or that central control failed. RFC 3149 allocated different powers to different places. Central software held changing business semantics: which numbered key meant which service, what label to display, what interface card to render and how a selection affected call logic. The phone retained immediate manipulation of audio hardware and mute.
That division reduced the need to hard-code every business service into every device while preserving a small physical control surface that did not wait for a controller round trip. It also created dependencies. A phone could keep muting locally while centrally assigned features failed; a Call Agent upgrade could change key meaning without changing hardware; a display deck could drift from signaling.
Running-code evidence resolves the ambiguity. If the Call Agent says key 1 is hold but the media continues, the feature did not produce the claimed result. If the mute lamp glows while audio leaves the microphone, local presentation and media reality diverge. If disp/ shows a redirect after ringing continues, display and signaling are out of phase exactly where the architecture said they could be.
The physical button is a small constitutional boundary. Central intelligence may assign names and coordinate calls. It does not acquire custody of every action merely because the endpoint reports to it.
Sources
- RFC 3149 text
- RFC 3149 record
- RFC 3149 HTML
- RFC 3149 document history
- RFC 2705 — MGCP 1.0
- RFC 2805 — Media Gateway Control requirements
- RFC 3015 — Megaco/H.248
- RFC 3435 — Revised MGCP 1.0
- RFC 3525 — Gateway Control Protocol
- RFC 3660 — Basic MGCP packages
- RFC 2897 — MGCP advanced audio packages
- XML 1.0, 1998 Recommendation
- Running-Code Primacy
- On Reality Layers
- 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
