VoIP Gateway: How TDM-to-IP Conversion Works and Where the SBC Fits

Most “all-IP” voice networks still touch copper somewhere. A primary rate interface (PRI) into a legacy PBX, an SS7 link to a wholesale carrier, an analog tie line to a building nobody wants to recable. Until that last circuit is gone, something has to translate the circuit-switched world into packets, and packets back into circuits. That job belongs to a VoIP gateway.

A VoIP gateway, also called a media gateway, terminates time-division multiplexed (TDM) circuits and converts both the call signaling and the audio into IP, usually SIP for signaling and RTP for media. In this article, we’ll walk you through what a gateway physically does, how TDM signaling maps onto SIP, how media conversion at the gateway differs from the transcoding a session border controller (SBC) performs, and where the gateway boundary ends and the SBC boundary begins. If you’re an engineer planning a TDM-to-IP migration or sizing an interconnect, this is the layer that decides how cleanly the old network meets the new one.

What a VoIP Gateway Actually Does

A VoIP gateway has two jobs, and it does them at the same time on every call. The first is signaling conversion: turning circuit-switched call control into SIP. The second is media conversion: lifting voice samples off a TDM timeslot and packetizing them into RTP, and doing the reverse in the other direction.

The terminology around this function is loose. “VoIP gateway,” “voice gateway,” “media gateway,” “PSTN gateway,” and “TDM to IP gateway” are largely interchangeable labels for the same box. A voip media gateway aimed at a carrier interconnect and a small voice gateway fronting an office PBX differ in density and interface count, not in principle. Both terminate circuits on one side and speak SIP on the other.

On the TDM side, the physical interfaces are the ones that have carried voice for decades: T1 and E1 spans, channelized DS3, optical OC3/STM-1 at carrier density, and analog FXO/FXS ports at the low end. A single platform might present anywhere from a couple of T1s to thousands of channels. What matters is that every one of those channels is a synchronous, clocked voice path that has to become an asynchronous stream of IP packets without the listener hearing the difference.

TDM Signaling and Its SIP Equivalents

The hardest part of the gateway’s work is not moving audio. It is making two completely different call-control models agree on when a call starts, connects, and ends. Each TDM signaling type maps onto SIP in its own way.

ISDN PRI uses Q.931 messages on the D-channel. A Q.931 SETUP becomes a SIP INVITE, CONNECT maps to a 200 OK, and DISCONNECT or RELEASE becomes a BYE. The bearer capability and called and calling number information elements translate into the SDP body and the relevant SIP headers, following the request semantics defined in RFC 3261. Q.931 itself is specified in ITU-T Q.931.

SS7 with ISUP is the carrier-grade case, where SS7 is a layered stack rather than a single protocol. MTP2 (link) and MTP3 (network) are the lower transport layers and run only over TDM, while ISUP (ISDN User Part) is the call-control layer that rides on MTP3 and sets up and tears down each call. A gateway can take ISUP in either of two ways: natively, terminating SS7 links with its own MTP2/MTP3 stack on a T1/E1; or over IP, where SIGTRAN carries the signaling and its adaptation layers stand in for the TDM transport (M3UA for MTP3 and the ISUP above it, M2UA or M2PA for MTP2). Once it has the ISUP messages, the gateway maps them to SIP: an Initial Address Message (IAM) opens the call as a SIP INVITE, an Answer Message (ANM) maps to 200 OK, and a Release (REL) becomes a BYE. The interesting detail is the cause codes: ISUP Q.850 release causes map to SIP response codes and back again, so a “user busy” on the TDM side surfaces as the correct SIP failure upstream. The full Q.850-to-SIP mapping is its own topic, as is the SIP response codes guide.

Channel-associated signaling (CAS), including T1 robbed-bit and E1 R2, encodes call state as in-band bit patterns and multi-frequency tone sequences rather than messages on a separate channel. The gateway has to detect those tones and bit transitions and convert them into clean SIP signaling, which is where accurate timing and tone detection matter most.

GR-303 and V5.2 handle access-side concentration, presenting line-side subscribers to a Class 5 switch over a managed interface. These show up when a gateway is replacing a Class 5 access function rather than a trunk.

Getting these mappings right is the difference between a migration that “mostly works” and one where supervision, billing, and disconnect handling behave exactly as they did on TDM.

Media Conversion: Where TDM Voice Becomes RTP

A TDM timeslot carries 64 kbps of pulse-code-modulated voice: G.711 µ-law in North America and Japan, A-law across most of the rest of the world. The gateway’s first media job is therefore packetization, not transcoding. It collects PCM samples, frames them into RTP packets per RFC 3550, and sends them to the IP peer, reversing the process for the return path.

This is worth separating clearly from transcoding. Converting the bearer from a timeslot into G.711 RTP is not the same as transcoding between IP codecs such as G.729, AMR, or Opus. Bearer packetization always happens at the gateway. Codec transcoding is a separate function that may live in the gateway, in a dedicated transcoding gateway, or behind an SBC, and it has a real cost in DSP capacity. The trade-offs between specific codecs are covered in the G.711 vs G.729 comparison, and the mechanics of mobile-to-IP conversion in the AMR to G.711 transcoding guide.

Timing is the subtler challenge. TDM is synchronous: every channel is locked to a network clock, and a sample arrives every 125 microseconds with no exceptions. IP is not synchronous at all. The gateway has to bridge that mismatch, recovering clock from the TDM side and absorbing packet delay variation on the IP side. Three functions have to survive the boundary intact: echo cancellation, since the hybrid junctions on legacy lines produce echo that a packet network will expose; DTMF, where in-band TDM tones are usually converted to out-of-band events; and fax, which typically moves to T.38 relay rather than riding a voice codec, as explained in the Fax over IP guide.

Where the Gateway Ends and the SBC Begins

This is the question that confuses most teams, so it is worth stating plainly. A media gateway and a session border controller sit at two different boundaries and do two different jobs.

A media gateway sits at the TDM-to-IP boundary. It terminates physical circuits, translates circuit-switched signaling into SIP, and packetizes voice into RTP. Take away the TDM circuits and a media gateway has nothing to terminate.

An SBC sits at an IP-to-IP boundary. It applies SIP security, hides topology, normalizes headers between mismatched vendors, enforces routing policy, handles encryption with TLS and SRTP, and applies STIR/SHAKEN. An SBC does not terminate TDM. A software SBC in particular speaks SIP and RTP on both legs and never sees a timeslot.

Plenty of networks need both. A gateway converts a carrier’s SS7 trunks or a legacy PBX’s PRIs into SIP, then hands that SIP to an SBC that secures it, normalizes it, and routes it into the IP core. Two boxes, two boundaries: the gateway makes the old network speak IP, and the SBC decides what happens to that IP traffic. Keeping the two roles distinct in your design avoids the common mistake of expecting a software SBC to terminate circuits, or expecting a bare media gateway to defend your network edge.

The Convergence of Gateway and SBC Functions

For years operators bought these as separate appliances: a rack of media gateways for TDM termination and a separate pair of SBCs for the IP edge. That separation is dissolving from both directions.

Modern carrier-grade media gateways fold SBC-style functions into the same platform, so the box that terminates SS7 also normalizes SIP, applies access control, and routes calls. At the same time, software SBCs have taken over the all-IP boundaries that no longer involve any TDM at all. The result is a spectrum rather than two fixed product categories.

The practical decision comes down to one question: how much TDM is actually left in your network? If the answer is none, an all-IP interconnect needs a software SBC and no gateway. If you still have PRIs, SS7 trunks, or analog endpoints, you need a media gateway at that edge, often one with SBC functions on board, paired with an SBC for the pure-IP side. And the TDM side keeps shrinking. Carrier PSTN sunsets are retiring TDM interconnects on a published timeline, which steadily moves traffic off gateways and onto SBCs. Designing for that trajectory means treating the gateway as the part of your network with a planned end date and the SBC as the part that grows.

Frequently Asked Questions

Bringing the Two Boundaries Together

A VoIP gateway owns the TDM-to-IP boundary: it terminates circuits, translates circuit-switched signaling into SIP, packetizes voice into RTP, and corrects the timing mismatch between a synchronous and an asynchronous network. An SBC owns the IP-to-IP boundary, where security, normalization, and routing live. Modern deployments converge those functions, and the TDM side shrinks as carriers retire the PSTN. Knowing which boundary you are solving for tells you which device you actually need.