Summary

  • RFC 3372 separated two jobs at the PSTN–IP boundary: encapsulating ISUP preserved legacy signaling for a capable endpoint, while translating selected facts into SIP headers made a request routable by SIP intermediaries.
  • Neither path was a receipt for the other. Preserved bytes did not prove correct routing or feature delivery; a successfully routed SIP request did not prove faithful ISUP reconstruction, media establishment or user experience.

Imagine a call leaving the telephone network, crossing an IP network, and re-entering the telephone network elsewhere. The originating gateway receives an ISUP message rich with telephone-network meaning. The SIP proxies in the middle need enough visible information to choose a destination. The terminating gateway may need the original ISUP detail to recreate features that SIP itself does not express.

RFC 3372, published in September 2002 as BCP 63, named the resulting framework SIP-T. Its authors were careful: SIP-T was not a new protocol. It was a set of practices for making traditional telephone signaling and SIP coexist. That modest description concealed a profound accounting problem. One call had to travel as two related records.

The first record was the encapsulated ISUP message. A gateway placed the legacy signaling object inside the SIP message body, using MIME types specified by RFC 3204. This channel preserved information that a later PSTN gateway might need, including parameters that had no clean SIP equivalent. In a PSTN-to-PSTN transit case, the far gateway could recover the body and use it as a template.

The second record was the SIP request itself. Proxies route on SIP-visible elements such as the Request-URI and headers. They cannot be expected to parse every ISUP variant. The originating gateway therefore translated selected ISUP facts—most obviously the called number—into SIP fields that intermediaries could understand and act upon.

RFC 3372 called the two objectives feature transparency and routability. Encapsulation served the first; translation served the second. Treating them as synonyms would have hidden two different failure modes. An intact body could cross the network while a mistranslated header led it to the wrong gateway. A correct route could deliver a request whose body was absent, damaged, unsupported or based on an incompatible ISUP variant.

The terminating gateway did not simply replay a sealed message. The framework said it could use encapsulated ISUP as a template, overwrite values derived from SIP headers, and apply local policy. If no ISUP body existed, it could start from a locally configured canonical template. Reconstruction was therefore an accountable act, not proof that the original call state had survived untouched.

The endpoint type was often unknown when the request began. A PSTN-originated call might end at another gateway or at a native SIP phone. A SIP phone might eventually reach the PSTN, but requiring every phone to generate ISUP would have been absurd. The originator could not select a fixed flow in advance. It supplied what it knew, and the eventual terminator interpreted what applied.

A native SIP endpoint generally ignored the encapsulated ISUP. It still had to tolerate multipart MIME and unknown content gracefully. This is an understated interoperability rule: not understanding an attached legacy record was different from rejecting the whole request. RFC 2046 supplied the multipart foundation; RFC 3261 supplied SIP's session framework.

Mid-call signaling exposed another seam. Some ISUP information could arrive during a call without changing SIP session state. RFC 3372 pointed to the SIP INFO method from RFC 2976 as the carrier. Again, transport of a message did not establish that an endpoint understood its semantics or that a user-visible feature occurred.

Routing and numbering work sat nearby. RFC 3219 described TRIP for exchanging telephony routing information, while RFC 2916's ENUM work mapped telephone numbers into DNS-based service information. Those mechanisms could help determine where a SIP request should go. They did not replace the ISUP record required for legacy feature context.

Security did not collapse the two records either. RFC 3372 required SIP-T endpoints to support S/MIME signatures and recommended encryption, drawing on RFC 2633. A signature could protect carried content. It could not prove that a gateway translated the right field, chose the right egress, applied legitimate local policy or completed the bearer path.

Later documents sharpened neighboring parts of the landscape. RFC 3398 specified detailed SIP–ISUP interworking. RFC 3326 allowed a SIP message to carry protocol-qualified reasons, but a reason explained context rather than performing the protocol action. RFC 3331 and RFC 3332 placed SS7 adaptation functions over SCTP; they answer where link or MTP-user state lives, not SIP-T's question of how one call survives as both opaque legacy meaning and visible IP routing data.

The official record does not support an adoption census or a triumphant replacement story. It does support a precise historical lesson. Interworking was not a converter that turned one truth into another and discarded the source. It was a controlled coexistence of representations, each useful to a different actor.

Lu Heng's “Minimum Initial Specification” lens helps explain the restraint: standardize the smallest common machinery, then leave localized decisions visible. “On Reality Layers” adds the evidentiary discipline. Received SS7, encapsulated body, translated header, proxy route, reconstructed egress message, bearer path and human experience belong to related but distinct reality layers.

The Internet did not absorb the telephone network by making those layers identical. RFC 3372 made the boundary operable by admitting that a gateway had to preserve what the old system said while separately exposing what the new system could route. The dual record was not redundancy. It was the price of crossing architectures without pretending that carriage and meaning were the same proof.

Sources