23B+D
A Primary Rate Interface in North America is delivered on a T1 and channelized as 23B+D: twenty-three bearer channels at 64 kbps each, plus one D-channel, also at 64 kbps, which handles signaling for all twenty-three.
That is the whole idea. Instead of stealing bits from the voice path to carry supervision — see robbed-bit signaling in T1 & fractional T1 — ISDN gives signaling a dedicated channel. This is common channel signaling, and it buys three things:
- Clear 64 kbps bearer channels. Nothing is robbed, so the B-channel carries genuine clear-channel data as well as voice.
- Much richer call control. Caller ID, DNIS, calling name, redirecting number, call-by-call service selection, and a real set of cause codes all become possible because there is a signaling channel with room to carry them.
- Faster call setup, because signaling is not constrained by the timing of in-band supervision.
| Interface | Structure | Usable calls |
|---|---|---|
| PRI (T1, North America / Japan) | 23B + 1D | 23 concurrent |
| PRI (E1, most of the world) | 30B + 1D | 30 concurrent |
| BRI | 2B + 1D (D at 16 kbps) | 2 concurrent |
On an E1 PRI the frame has 32 timeslots. TS0 carries framing and TS16 carries the D-channel, leaving 30 bearer channels — which is why you will see it written as both "30B+D" and, counting TS0, "30B+2D." The former is the conventional description.
NFAS: sharing one D-channel across several PRIs
Giving up a channel to signaling on every span is wasteful once you have several. Non-Facility Associated Signaling (NFAS) lets one D-channel control the B-channels on multiple T1s — so a second span contributes 24 bearer channels rather than 23.
Most implementations also allow a backup D-channel on another span, because a single D-channel failure would otherwise take down every call path it controls.
The D-channel and Q.931
The D-channel runs a layered protocol stack. Layer 2 is LAPD (Q.921), which provides reliable framing. Layer 3 is Q.931, which is the call control protocol proper — the thing that actually sets up and tears down calls.
A simplified inbound call looks like this:
| Message | Direction | Meaning |
|---|---|---|
| SETUP | Network → PBX | Incoming call, with called and calling number information |
| CALL PROCEEDING | PBX → Network | Request accepted, channel selected |
| ALERTING | PBX → Network | The destination is ringing |
| CONNECT | PBX → Network | Answered — this is where billing starts |
| DISCONNECT / RELEASE | Either | Teardown, carrying a cause code |
Those cause codes are worth knowing, because they survive into the SIP world through mapping. Cause 16 is normal clearing. Cause 17 is user busy. Cause 34 is no circuit available — the one that means you have run out of channels, and the one that should be driving a capacity conversation rather than a support ticket.
Switch protocol variants
PRI is standardized, and then it is not. The switch type has to match at both ends:
- NI-2 — National ISDN-2, the common interoperable choice
- 5ESS — Lucent/AT&T custom
- DMS-100 — Nortel custom
- 4ESS — historically used for AT&T long distance services
- QSIG — for PBX-to-PBX tie trunks, with feature transparency between nodes
A switch type mismatch produces a D-channel that will not come into service, or one that establishes and then rejects calls with unexpected cause codes. If you are documenting an estate before migration, record the switch type per span — it tells you something about the age and origin of the service.
What has to be reproduced in SIP
This is the section that matters for a migration. A PRI is not simply "23 calls." It is a set of behaviors the business has been depending on, often without documenting them.
| PRI behavior | SIP equivalent | Where it goes wrong |
|---|---|---|
| Calling party number | From / P-Asserted-Identity | Carriers differ on which header they trust for billing and for caller ID display. Get it in writing. |
| Calling name (CNAM) | Network lookup, not passed in signaling | Frequently assumed to carry over. It generally does not — it becomes a separate, chargeable service. |
| DNIS / called number | Request-URI | Digit count differs. PRIs are often provisioned to deliver 4 digits; SIP delivers full E.164. Dial plans break on this. |
| Redirecting number | Diversion or History-Info | Two competing conventions. Pick one per carrier and test forwarded-call scenarios explicitly. |
| Call-by-call service selection | Multiple trunks or header-based routing | No direct equivalent. Needs redesign rather than translation. |
| Two-B-channel transfer | REFER | Carrier support for REFER varies. Where unsupported, media stays anchored on your SBC and consumes capacity. |
| Cause codes | SIP response codes | Mapping is defined but lossy. Reporting built on specific cause codes will need rework. |
| Fixed 23 channels | Call admission control | The limit becomes a policy you configure, not a physical fact. If nobody sets it, there is no limit — until the bill arrives. |
Why PRI lasted so long
It is worth being fair to the technology. PRI is deterministic, it either works or it does not, its capacity is unambiguous, and its failure modes are well understood by anyone who has worked with it. Those are real virtues, and they are the reason organizations are reluctant to leave.
What replaces it is more capable and less predictable. Planning the migration well is largely about restoring predictability by other means: explicit capacity policy, measured quality targets, and tested behavior rather than assumed behavior.
Related reading
- T1, DS1 & fractional T1 — the circuit underneath.
- SS7 & call signaling — how the same job is done between carriers.
- SIP trunking & SBCs — the destination architecture.
Sources
Feature parity matrices are unglamorous and they are the reason cutovers go quietly.
Book a call