Summary

  • RFC 3136 described a SPIRITS architecture in which a telephone-network trigger could notify an Internet user and carry the user's chosen call disposition back toward telephone service control.
  • The selection was not the treatment itself. A gateway and SPIRITS Client still had to relay it, the Service Control Function had to transform it into an action, and the switch had to resume call processing before any caller-visible result existed.

The button was at the edge of two systems

In the dial-up Internet of 2001, one copper line could carry either a modem session or an ordinary incoming call. The line's owner might be reading the web while a caller encountered the telephone network. Internet Call Waiting promised to connect those worlds without pretending they had become one.

The subscriber's computer could display the caller's number or name and offer a menu. End the Internet session and take the call. Forward it to another number. Send it to voice mail. Play a recorded message. Reject it. In some descriptions, voice over IP was another possibility, although RFC 3136 expressly said that its proposed architecture did not cover that feature.

The menu made the moment legible. It also made the wrong conclusion tempting. Once the subscriber pressed “forward,” a screen could immediately report that a choice had been made. Yet no call had necessarily reached the alternate number. The button existed in an IP host; the suspended call existed in a telephone switch. Between them lay several actors, several interfaces and several opportunities for delay, rejection or failure.

RFC 3136's contribution was to draw that distance. Published in June 2001 as an Informational RFC, The SPIRITS Architecture did not specify a complete protocol. It named components and the logical paths among them for services that originated in the public switched telephone network and needed Internet interaction. The document's modest status matters: an architecture can tell us where a decision must travel without proving that a particular network implemented the path.

The trigger belonged to the telephone network

The first fact did not come from the browser. A Service Switching Function, normally located in a telephone switch, recognized an Intelligent Network trigger and interacted with a Service Control Function. The SCF executed service logic and could instruct switches how to complete the call.

That is the first boundary in the chain. A line ringing, a switch recognizing the relevant trigger, and service control being invoked were related events, not synonyms. If the trigger was absent, misprovisioned or never reached the SCF, no Internet notification could repair the missing beginning. If the trigger fired, that fact still did not say that the subscriber had been told.

RFC 3136 placed a SPIRITS Client on the telephone-control side. It received requests from the SCF and returned responses. The Client could be co-located with the SCF or communicate with it over interface D. That qualification prevents the diagram from being read too literally. Logical roles describe responsibility; they do not prove separate boxes, vendors or administrative domains.

The architecture then used a SPIRITS Gateway as an intermediary between telephone-side and Internet-side functions. The Gateway could be co-located with PINT components. A SPIRITS Server handled interactions with the subscriber: incoming-call notification and the relay of the selected treatment. Again, “server,” “gateway” and “client” were responsibility labels. Co-location could reduce hops without erasing the evidentiary stages.

Five interfaces, five different claims

RFC 3136 labelled its interfaces A through E. Their differences are more valuable than the alphabet suggests.

Interface A carried PINT requests from the subscriber's host to a PINT Server. In the SPIRITS scenario, its principal role was session registration and therefore service activation; it might also be used for subscription. A successful registration established an activated relationship for a period. It did not prove that a later telephone trigger occurred, that the Internet host remained reachable, or that a selected treatment would be executed.

Interface B crossed between the subscriber's SPIRITS Server and the Gateway. It had two principal purposes: notify the subscriber of an incoming call, including name or number when available, and carry the subscriber's on-the-fly disposition toward the Gateway. The two directions were connected but not symmetrical. Receiving the notification did not prove that a response returned. Sending a disposition did not prove that the Gateway accepted or forwarded it.

Interface C connected the Gateway to the telephone-side SPIRITS Client. RFC 3136 permitted the Gateway to communicate with the SPIRITS Server or act as a virtual server and terminate requests itself. A log at the Gateway could therefore mean different things under different realizations. “Terminated here” might be a valid architectural endpoint, not evidence that a message continued to another process.

Interface D connected the SPIRITS Client and the SCF. Trigger parameters moved from service control toward the Client. The user's call disposition moved back. This was where RFC 3136 made its decisive statement: the SCF “transforms” the user's disposition into appropriate actions and resumes suspended call processing in the Service Switching Point.

Interface E sent PINT requests to the SCF for execution. PINT ran in the reverse direction—an Internet request asking the telephone network to perform a service—but RFC 3136 reused its functions for registration and a combined architecture. Reuse did not make a PINT request, a SPIRITS notification and a telephone action one record.

The choice still needed translation into action

Suppose the subscriber chooses “reject.” The IP host can record the click with perfect accuracy. The SPIRITS Server can serialize it. The Gateway can accept it. The Client can pass the disposition over interface D. None of those records is yet the announcement heard by the caller or the release of the suspended call.

The SCF owns another judgment. It must interpret the user's selected disposition in the context of service logic and current call state, then convert the abstract choice into actions understood by the telephone network. “Reject” may require an announcement and disconnection. “Forward” needs a destination, eligibility and further call processing. “Accept” may require ending the dial-up session before the line can carry voice. Each step has its own policy and failure surface.

Then the switch must act. The call may already be suspended while service control waits. A response that arrives too late can be correct as a message and useless as treatment. A forward destination may be syntactically valid but unreachable. A prerecorded announcement may begin without being heard. A voice-mail system may answer without retaining a usable message. The architecture did not promise to observe every final effect.

The evidence ladder is therefore longer than the interface diagram: registration; trigger recognition; notification emission; notification delivery and rendering; disposition selection; Server/Gateway/Client receipt; SCF transformation; switch resumption and execution; destination result; and independent readback. A receipt at one rung cannot silently certify the next.

A call log was still an observer's account

RFC 3136 described automatic dispositions as well as real-time choices. A subscriber could establish a default treatment or a rule for particular originating numbers. The system could process the call without presenting it live, then let the subscriber inspect a log containing time, calling number, calling name and disposition.

The log was useful. It was not omniscient. “Forward” might record the selected policy, the instruction emitted by service control, or a result classified by an implementation. Those are different events. Unless the record specifies its observation point and completion rule, it cannot establish whether the alternate line rang, a person answered, the caller heard the expected announcement or the downstream system retained anything.

The earlier RFC 2995 surveyed four pre-SPIRITS implementations and showed why this caution was necessary. All supported Internet Call Waiting, most used SIP, and all used Intelligent Network mechanisms on the telephone side. But the document expressly said the implementations did not all interoperate, and even the SIP-based ones did not necessarily share a SIP version. “SPIRITS server” did not have one universal meaning across those systems.

That running-code evidence was real but bounded. It showed that named organizations had built SPIRITS-like services and reported particular call flows. It did not turn every component in RFC 3136 into a deployed universal interface, or every recorded “success” into an independently verified caller outcome.

Notification and control were not the same service

The later protocol requirements in RFC 3298 sharpened the distinction. They required the minimum SPIRITS protocol to support basic notification without depending on PINT services or persistent interaction with the telephone network. A system could therefore tell an Internet host that an event occurred without providing the same host with power to alter the call.

For call treatment, RFC 3298 drew the remaining chain explicitly: registration, event notification, call disposition, Service Control, and the SSP. It called reaction to the notification the remaining element necessary for delivery of the SPIRITS service. The disposition vocabulary included accept, reject and redirect; accepting through voice over IP remained outside the working group's scope.

This was a useful limit on user-interface design. A notification card can truthfully say “incoming call” while offering no control. A control button can truthfully say “request sent” while execution remains pending. Combining both into one green check mark would erase the very architecture the standards work had separated.

RFC 3910, published in 2004, later specified SPIRITS event packages using SIP SUBSCRIBE and NOTIFY plus XML. It renamed the confusing logical roles for the protocol discussion: the Internet-side server was a subscriber to events; the telephone-side client was a notifier. The names changed because who initiated a subscription and who emitted a notification mattered more than which side had once been called client or server.

The protocol also distinguished detection points that requested a response from those that merely notified. A request detection point suspended call processing until a response arrived. A notification detection point allowed processing to continue after the event was reported. The same event vocabulary could therefore sit on two different authority paths. Seeing a NOTIFY did not tell an operator that the call had paused for Internet judgment.

Even subscription acceptance had stages. RFC 3910 allowed a 202 response followed by an immediate NOTIFY saying the request had been accepted and was being acted on, then another NOTIFY after the detection points had been initialized. A 200 path could skip the “being acted on” state but still required state notification. Accepted, initialized and later fired were deliberately separate.

The most consequential interface stayed local

RFC 3910 focused on interfaces B and C. It said interface D—the connection to the SCF—was a matter of local policy and did not specify it in detail. That is not a missing footnote. Interface D sat precisely where an Internet-side disposition could become telephone service logic.

The common protocol could standardize subscriptions, notifications and mandatory XML elements while the operator retained the consequential integration with its service-control system. One operator might use a functional interface; another might use message passing; co-location might collapse the transport hop. The public specification stopped before claiming a universal execution mechanism.

That division reflects a broader Internet pattern. A portable message can carry a proposed action across an organizational boundary. The receiving system still decides whether the sender is known, whether the request is authorized, whether its state is current, whether the action is available and how to map it into local machinery. Interoperable syntax reduces ambiguity. It does not abolish local authority.

Trust followed the action, not the diagram

RFC 3136 treated interface B as generally crossing the public Internet and therefore especially exposed to theft and denial of service. Interface C was more likely to run across a provider intranet, but the Gateway's Internet connection joined that intranet to an external attack surface. The RFC warned that a firewall alone could be insufficient.

The risk was not limited to keeping messages secret. A fraudulent registration could redirect notifications. A modified disposition could reject, forward or disclose information about calls. A replayed or stale choice could affect the wrong event. A legitimate subscriber might be authenticated but no longer entitled to control the line. The Gateway could trust the Server while the SCF's current service policy denied the requested treatment.

Thus authentication, integrity, subscription validity, line association, disposition authority, service-control policy and switch execution need separate receipts. “The user clicked it” is a statement about intent at one interface. It is not a universal mandate over every actor downstream.

The architecture's honesty was its lasting result

SPIRITS belongs to a particular moment: dial-up Internet sessions, circuit-switched calls and ambitious attempts to make telephone triggers available to Internet services. The interfaces may look historical now. The control problem is not.

Modern systems still present a button at the edge of somebody else's execution domain. A dashboard can request failover, revoke a credential, move traffic, cancel a payment or redirect a conversation. The button produces intent. A gateway authenticates it. A policy engine interprets it. A controller translates it. A device acts. A later observer decides whether the result occurred.

RFC 3136 did not collapse those layers. It drew them. The subscriber could choose the treatment, but the network still had to turn the choice into a fact.