Voice over IP (VoIP)

What is VoIP?

VoIP (Voice over Internet Protocol) transmits voice communications over IP networks — the same packet-switched infrastructure that carries email, web traffic, and streaming video. Instead of dedicating a 64 kbps circuit for the duration of a call (as in circuit-switched telephony), VoIP digitizes, compresses, and segments voice into packets that share bandwidth with other traffic using statistical multiplexing.

The fundamental advantage is efficiency. A traditional T1 line carries exactly 24 simultaneous calls at 64 kbps each, whether the speakers are talking or silent. VoIP with silence suppression (VAD — Voice Activity Detection) reduces bandwidth by 40–60% during natural conversation pauses. Combined with compression codecs (G.729 at 8 kbps or Opus at variable bitrate), a single 1 Mbps connection carries 50–100 simultaneous VoIP calls — capacity that would require 3–5 T1 lines in the circuit-switched world.

Analog-to-Digital Conversion

The process begins at the endpoint — a SIP phone, softphone, or analog telephone adapter (ATA). A microphone captures sound pressure waves and converts them to an analog electrical signal. An ADC (Analog-to-Digital Converter) samples the signal at a rate determined by the Nyquist theorem: to faithfully represent a signal with maximum frequency f_max, the sampling rate must be at least 2 × f_max. For telephony voice (300–3400 Hz), the standard sampling rate is 8,000 Hz, capturing frequencies up to 4 kHz.

Each sample is quantized to a digital value. In G.711 (the telephony standard), each sample is 8 bits, yielding a raw data rate of 8,000 × 8 = 64,000 bps (64 kbps). For wideband codecs like G.722, the sampling rate doubles to 16,000 Hz, capturing frequencies up to 7 kHz, but the RTP clock rate remains 8,000 Hz for backward compatibility — each 20 ms frame increments the RTP timestamp by 320 (16,000 × 0.02) rather than the expected 160.

After sampling, the raw PCM stream is passed to the selected codec for compression. The codec divides the continuous stream into frames — fixed-duration blocks of samples that are encoded as a unit. Frame size determines one component of algorithmic delay: a 20 ms frame cannot be transmitted until all 160 samples (at 8 kHz) are collected.

Voice Codecs

G.711 — Pulse Code Modulation (ITU-T, 1972)

G.711 is the foundational voice codec — uncompressed PCM with logarithmic companding. It operates at 64 kbps(8,000 samples/sec × 8 bits/sample) and provides toll-quality voice with no algorithmic delay (<1 ms). Two companding laws exist: μ-law (North America, Japan) and A-law(Europe, rest of world). Both map 14-bit linear PCM samples to 8-bit compressed values using a piecewise-linear approximation to a logarithmic curve.

μ-law compression encodes 14-bit linear values into 8 bits using 15 non-linear segments with 16 quantization levels each. The compression formula is:

μ-law: y = sign(x) × ln(1 + μ|x|/X_max) / ln(1 + μ), where μ = 255

This provides finer quantization at low amplitudes (where speech spends most of its time) and coarser quantization at high amplitudes — a form of perceptual quantizationthat trades signal-to-noise ratio at high amplitudes for improved SNR at low amplitudes, matching human hearing's logarithmic sensitivity.

Each 20 ms frame contains 160 samples (160 bytes at 8 bits each). The RTP timestamp increments by 160 per frame. Payload type PT 0 (PCMU) and PT 8(PCMA) are static payload types defined in RFC 3551 — no SDP negotiation is needed; either endpoint can send PT 0 or 8 without prior agreement.

G.711 Appendix I defines a PLC (Packet Loss Concealment) algorithm: when a frame is lost, the PLC uses pitch detection (searching for periodicity in the range 40–120 samples, corresponding to 66–200 Hz) on a 48.75 ms history buffer (390 samples), then generates replacement waveform by repeating pitch periods with overlap-add (OLA) using a triangular window and an attenuation factor of 0.2 per 10 ms frame. The output is delayed 3.75 ms (30 samples) to allow look-ahead. This adds minimal latency while providing subjectively acceptable concealment for up to 2–3 consecutive lost frames.

G.729 — CS-ACELP (ITU-T, 1996)

G.729 compresses voice to 8 kbps using Conjugate-Structure Algebraic-Code-Excited Linear Prediction (CS-ACELP). Each 10 ms frame (80 samples) is encoded into exactly 10 bytes (80 bits), plus a 2-byte frame header in some implementations. The algorithm models the human vocal tract as a linear predictive filter and excites it with codebook vectors.

The encoder performs a 10th-order LP (Linear Prediction) analysis on each frame, converting the resulting LP coefficients to Line Spectral Frequencies (LSFs) for quantization. The LSFs are encoded using 4 codebooks (L0, L1, L2, L3) totaling 18 bits per frame. Each frame is divided into 2 sub-frames of 40 samples (5 ms each).

The bit allocation per 80-bit frame is:

• LSP quantization: 18 bits
• Adaptive codebook delay (pitch): P1 = 8 bits, P2 = 5 bits + 1 bit parity (P0) = 14 bits
• Fixed codebook index: C1 = 13 bits, C2 = 13 bits = 26 bits
• Fixed codebook sign: S1 = 4 bits, S2 = 4 bits = 8 bits
• Codebook gains (stage 1 + stage 2): GA1/GB1/GA2/GB2 = 3+4+3+4 = 14 bits
• Total: 80 bits = 10 bytes

The algorithmic delay is 15 ms: 10 ms frame plus 5 ms lookahead. The perceptual weighting filter uses γ1 = 0.94 and γ2 = 0.60 (configurable per ITU-T test conditions) to shape the error spectrum away from formant frequencies. G.729 achieves a MOS of approximately 3.9 — slightly below G.711's 4.1–4.2 but at 1/8 the bandwidth.

G.729b (annex B) adds VAD (Voice Activity Detection) andDTX (Discontinuous Transmission): during silence periods, the encoder transmits Silence Insertion Descriptor (SID) frames at a reduced rate, further saving bandwidth during conversation pauses. The patents on G.729 expired in 2017, making it royalty-free.

G.722 — Wideband SB-ADPCM (ITU-T, 1988)

G.722 doubles the audio bandwidth to approximately 50–7,000 Hz (wideband) by sampling at 16,000 Hz. It uses Sub-Band Adaptive Differential Pulse Code Modulation (SB-ADPCM): the signal is split into two sub-bands (low: 0–4 kHz, high: 4–8 kHz) using a QMF (Quadrature Mirror Filter) filter bank, and each sub-band is independently ADPCM encoded. Bit rates are selectable at 48, 56, or 64 kbps.

Despite the 16 kHz sampling rate, G.722 uses an 8,000 Hz RTP clock ratefor historical compatibility — the timestamp increments by 320 for a 20 ms frame (16,000 × 0.02 = 320 samples, but the clock runs at 8,000 Hz so 320/8000 = 40 ms worth of ticks... actually the timestamp simply increments by 320 per frame). This quirk means G.722 appears as PT 9 (a static type) and must be carefully handled by middleboxes that assume 8 kHz sampling for PT 9. Algorithmic delay is <2 ms. MOS: approximately 4.2.

Opus — Hybrid SILK + CELT (IETF RFC 6716, 2012)

Opus is the modern standard for VoIP audio — a royalty-free, adaptive codec that seamlessly transitions between three operating modes:

• SILK-only mode:Linear prediction codec optimized for speech at low bitrates (6–40 kbps). Narrowband to wideband. Based on Skype's SILK codec.
• Hybrid mode (SILK + CELT): SILK handles frequencies below 8 kHz (linear prediction), CELT handles above 8 kHz (MDCT). Super-wideband and full-band speech at medium bitrates (12–100 kbps).
• CELT-only mode: Modified Discrete Cosine Transform (MDCT) codec for music and very low delay. Full bandwidth at any bitrate. Based on the CELT codec from Xiph.org.

Opus supports sampling rates of 8, 12, 16, 24, and 48 kHz, with audio bandwidths from narrowband (4 kHz) to full-band (20 kHz). Frame sizes range from 2.5 ms to 60 ms, with algorithmic delay of 5–65.2 ms depending on frame size and mode. The bitrate is configurable from 6 to 510 kbps, and the encoder can switch between VBR (variable bitrate) and CBR (constant bitrate).

Sweet spots for common use: 8–12 kbps for narrowband speech, 16–20 kbps for wideband speech, 28–40 kbps for full-band speech, 48–64 kbps for mono music, 64–128 kbps for stereo music. The encoder requires approximately 70 MIPS at full complexity. Built-in features include FEC (forward error correction), DTX (discontinuous transmission), and PLC (packet loss concealment). Opus is the default codec for WebRTC, Discord, WhatsApp, and Signal.

The Opus TOC (Table of Contents) byte encodes the configuration (top 5 bits — 32 possible configurations), stereo flag (bit 4), and frame count code (bits 2–3). Timestamp increments are: 120 (2.5 ms), 240 (5 ms), 480 (10 ms), 960 (20 ms), 1920 (40 ms), 2880 (60 ms) — always at 48 kHz clock regardless of internal sampling rate.

Codec Comparison

┌──────────┬──────────┬──────────┬──────────┬──────────┐
│ Codec │ Bit Rate │ Sampling │ Delay │ MOS │
├──────────┼──────────┼──────────┼──────────┼──────────┤
│ G.711 │ 64 kbps │ 8 kHz │ <1 ms │ 4.1–4.2 │
│ G.722 │ 48–64k │ 16 kHz │ <2 ms │ 4.2 │
│ G.729 │ 8 kbps │ 8 kHz │ 15 ms │ 3.9 │
│ Opus │ 6–510k │ 8–48 kHz │ 5–65.2 ms│ 4.5+ │
└──────────┴──────────┴──────────┴──────────┴──────────┘

Packetization and RTP

RTP Packet Structure (RFC 3550)

Each VoIP packet carries a 12-byte RTP header followed by the codec payload. The RTP header fields are:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

• V (Version): 2 bits — always 2
• P (Padding): 1 bit — if set, last byte contains padding count
• X (Extension): 1 bit — if set, followed by 4-byte extension header
• CC (CSRC Count): 4 bits — number of contributing source identifiers (0–15)
• M (Marker): 1 bit — profile-dependent; typically marks start of a talkspurt after silence
• PT (Payload Type): 7 bits — 0–34 are static (RFC 3551), 96–127 are dynamic (SDP-negotiated)
• Sequence Number: 16 bits — increments by 1 per packet; random initial value
• Timestamp: 32 bits — sampling instant of first octet; at the codec's clock rate
• SSRC: 32 bits — randomly chosen, globally unique within the RTP session

Static Payload Types (RFC 3551)

Common static PT assignments: PT 0 = PCMU (G.711 μ-law), PT 3 = GSM, PT 4 = G.723, PT 8 = PCMA (G.711 A-law), PT 9 = G.722, PT 18 = G.729. Dynamic types (PT 96–127) are assigned via SDP — Opus typically uses PT 96 or 118, negotiated in the SDP offer/answer exchange.

Bandwidth Overhead Calculations

The total overhead per VoIP packet is 40 bytes (20 IP + 8 UDP + 12 RTP minimum). For 20 ms frames at G.711:

Payload: 160 bytes (160 samples × 8 bits, 20 ms)
Total packet: 160 + 40 = 200 bytes
Packets/sec: 1000 ms / 20 ms = 50 pps
Bandwidth: 200 × 8 × 50 = 80,000 bps = 80 kbps
Overhead: 40 × 8 × 50 = 16,000 bps = 16 kbps (25% overhead)

For G.729 at 20 ms frames: payload = 10 bytes, total = 50 bytes, bandwidth = 50 × 8 × 50 = 20 kbps (8 kbps payload + 12 kbps headers = 60% overhead). This overhead ratio is why header compression (cRTP — compressed RTP, reducing 40-byte headers to 2–4 bytes) is critical on low-bandwidth links.

For Opus at 32 kbps with 20 ms frames: payload = 80 bytes, total = 120 bytes, bandwidth = 48 kbps (32 kbps payload + 16 kbps headers).

SIP — Session Initiation Protocol

SIP (RFC 3261)is the text-based signaling protocol that establishes, modifies, and terminates VoIP calls. It runs over UDP or TCP on port 5060 (unencrypted) or port 5061 (TLS). SIP handles call setup and teardown — it does not carry voice media (that is RTP's job).

SIP Message Format

SIP messages are text-based, modeled on HTTP. A SIP INVITE request (from RFC 3261 §7.1):

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142

The mandatory headers on every SIP request (RFC 3261 §8.1.1) are: Via(tracks the route), Max-Forwards (loop prevention, starts at 70),To, From (with tag for dialog identification),Call-ID (globally unique, typically user@host format), andCSeq (sequence counter + method name). INVITEs almost always includeContact (direct reachability URI). Compact header forms exist: Via→v, From→f, To→t, Call-ID→i, Contact→m, Content-Type→c, Content-Length→l.

Call Flow

A basic SIP call between two endpoints:

• INVITE — Caller sends INVITE with SDP offer (IP, port, codecs). Traverses proxies to reach callee.
• 100 Trying — First proxy acknowledges receipt (stops retransmission).
• 180 Ringing — Callee's phone ringing; ringback tone played to caller.
• 200 OK — Callee answers; response contains SDP answer (selected codec).
• ACK — Caller confirms. RTP media begins flowing.
• BYE — Either party hangs up; other responds with 200 OK; media stops.

SDP — Session Description Protocol

SDP (RFC 4566) is embedded in SIP messages to describe media parameters. An SDP offer contains: IP address and port for RTP, codecs in preference order (with clock rates and parameters), bandwidth constraints, and special attributes. The called party responds with an SDP answer selecting the mutually preferred codec. Example SDP payload for G.711 + Opus:

v=0
o=alice 2890844526 2890844526 IN IP4 pc33.atlanta.com
s=-
c=IN IP4 pc33.atlanta.com
t=0 0
m=audio 49170 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 opus/48000/2
a=fmtp:96 minptime=20;useinbandfec=1
a=ptime:20

SIP Transaction State Machines

SIP defines four transaction types with strict state machines. The INVITE Client Transaction (ICT) follows: calling → proceeding → completed → terminated. Timer A (retransmit interval) starts at 500 ms (T1) and doubles on each retransmit up to 4 seconds. Timer B (total timeout) = 64 × T1 = 32 seconds. TheNon-INVITE Client Transaction (NICT) follows: trying → proceeding → completed → terminated, with Timer E doubling from 500 ms to 4 seconds and Timer F at 32 seconds.

Transport considerations: SIP over UDP (default, port 5060) is stateless but subject to fragmentation — Ethernet MTU of 1500 bytes minus IP (20) minus UDP (8) = 1472 bytes usable payload; SIP messages exceeding this cause IP fragmentation. TCP (port 5060) avoids fragmentation but introduces head-of-line blocking. TLS (port 5061) adds 20–40 bytes of record layer overhead. WebSocket (ports 80/443) is used by WebRTC browser endpoints.

VoIP Quality: Jitter, Latency, and Packet Loss

Jitter Estimation (RFC 3550 §A.8)

The interarrival jitter is estimated as a statistical estimate of the mean deviation of the data packet interarrival time:

J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

Where D(i-1,i) = (R_i - S_i) - (R_{i-1} - S_{i-1}), R_i is the arrival time (in RTP timestamp units) and S_i is the RTP timestamp of packet i. The jitter value is reported in RTCP Receiver Report packets as a 32-bit unsigned integer.

Jitter Buffers

IP networks deliver packets with variable delay (jitter). The jitter buffercollects packets and plays them out at regular intervals, smoothing irregular arrivals into continuous audio. The trade-off is latency: a larger buffer handles more jitter but adds delay.

Fixed jitter buffers use a static depth (e.g., 60 ms). Packets arriving after the buffer deadline are discarded. The ITU-T G.1020 standard approximates mean occupation delay as 0.5 × buffer size when the exact jitter distribution is unknown.

Adaptive jitter buffers dynamically adjust depth based on measured jitter, expanding during congestion and shrinking during stable periods. The 3GPP TS 26.448 standard (for EVS codec jitter buffers) specifies: playout delay estimation with long-term FIFO tracking, Time-Scale Modification (TSM) for frame-based adaptation, and Adaptation Control Logic for deciding playout timing. Typical buffer sizes: 20–60 ms.

Latency Requirements

ITU-T G.114 specifies a maximum one-way delay of 150 ms for acceptable conversational quality. Beyond 150 ms, speakers begin talking over each other. The total latency budget:

• Codec algorithmic delay: 0.125 ms (G.711) to 25 ms (G.729) to 65 ms (Opus)
• Packetization delay: 20 ms (for 20 ms frames)
• Network propagation: 5–50 ms (distance-dependent)
• Jitter buffer: 20–60 ms
• Processing delay: 5–15 ms (encoding, packetization, routing)

G.114 thresholds: <150 ms one-way = acceptable; 150–400 ms = acceptable with impairments; >400 ms = unacceptable. For satellite links (250–300 ms round-trip), VoIP is challenging but usable with echo cancellation.

Packet Loss

VoIP quality degrades rapidly with packet loss. G.711 with PLC remains intelligible up to about 5–10% packet loss. Beyond 10%, gaps become audible as clicks. G.729 is more vulnerable because its codebook-based decoding relies on sequential frames. FEC (forward error correction) and redundant encoding (sending the same audio in multiple packets) trade bandwidth for resilience.

Echo Cancellation

Echo in VoIP comes from two sources: acoustic echo (speaker-to-microphone coupling in hands-free devices) and hybrid echo (electrical reflections at the 2-wire/4-wire conversion point where VoIP meets the PSTN).

G.168 Requirements

ITU-T G.168 specifies the performance requirements for digital network echo cancellers:

• ERL (Echo Return Loss): ≥6 dB minimum from the hybrid
• ERLE (Echo Return Loss Enhancement): ≥18 dB from the adaptive filter alone
• Combined Loss (ACOM): ≥55 dB total (AECHO + ACANC + ANLP)
• Tail Length: 8–128 ms configurable; 32 ms standard, 64 ms extended
• NLP (Non-Linear Processor) Loss: ≥25 dB additional when activated
• Convergence Time: Time to reach specified performance after echo path change

Adaptive Filter Algorithm

The NLMS (Normalized Least Mean Squares) algorithm is the standard for echo cancellation:

w(n+1) = w(n) + α × e(n) × x(n) / (δ + ||x(n)||²)

Where w(n) is the filter weight vector, α is the step size (0 < α < 2, typically 0.5–1.0), e(n) is the error signal, x(n) is the reference signal, and δ is a regularization parameter. The filter length M = tail_length × sampling_rate — for a 32 ms tail at 8 kHz, M = 256 taps. Convergence requires 16-bit coefficient precision (minimum 13.6 bits for 48 ms tail per G.168).

Double-talk detectionfreezes adaptation when both speakers are active simultaneously — without this, near-end speech corrupts the filter's reference signal, causing divergence. Energy-based detectors compare near-end/far-end signal levels to detect double-talk conditions.

Quality of Service (QoS)

DSCP Marking (RFC 4594)

Enterprise VoIP deployments use DSCP (Differentiated Services Code Point) marking to prioritize voice packets:

• EF (Expedited Forwarding, DSCP 46): RTP voice media — mapped to strict priority queue (LLQ) in routers. ToS byte = 184 (0xB8).
• CS3/AF31 (DSCP 24/26): SIP signaling traffic
• AF41 (DSCP 34): Video conferencing
• CS0 (DSCP 0): Best effort / default

Layer 2 prioritization uses 802.1p (3-bit field in VLAN tag): CoS 5 = voice, CoS 3 = signaling, CoS 0 = best effort. Best practice: use 802.1p CoS 5 within the LAN/VLAN and DSCP EF 46 for WAN/routed segments.

MOS and the E-model (ITU-T G.107)

The E-model computes an R-factor (rating factor) that predicts subjective voice quality:

R = Ro - Is - Id - Ie + A

Where Ro = basic signal-to-noise ratio, Is = impairments simultaneous with speech (quantization, clipping), Id = impairments due to delay, Ie = equipment impairment factor (codec-specific), and A = advantage factor (compensation for access type, e.g., mobile = 10). The R-factor maps to MOS via:

MOS = 1 + 0.035·R + R·(R - 60)·(100 - R)·7×10⁻⁶
(clamped: R < 0 → MOS = 1.0; R > 100 → MOS = 4.5)

Equipment impairment factors (Ie) for common codecs: G.711 = 4.3, G.722 = 0, G.726 (32k) = 7, G.729 = 11, G.723.1 (5.3k) = 21. The default R-factor with all parameters at default is R = 94.2 — very high quality. Carrier-grade targets: MOS > 4.0, R-factor > 90, one-way delay < 150 ms, packet loss < 1%.

NAT Traversal and Session Border Controllers

The NAT Problem

VoIP encounters a fundamental problem with NAT: SIP and SDP embed IP addresses in the message body and headers, but NAT translates addresses at the network layer without updating the application layer. A SIP phone behind a NAT router advertises its private IP (e.g., 192.168.1.50) in SDP, but the remote endpoint cannot route RTP packets to that private address.

Solution Methods

• STUN (RFC 5389): A STUN server on the public internet tells the client its public IP and port (server-reflexive candidate) for use in SDP.
• TURN (RFC 5766): When STUN fails (symmetric NAT), a TURN server acts as a media relay, forwarding RTP between the endpoint and public network.
• ICE (RFC 8445): Combines STUN and TURN, trying multiple candidate addresses (host, server-reflexive, relay) to find the best path. ICE is the standard solution for WebRTC.
• SBC (Session Border Controller): A B2BUA at the network boundary that rewrites SIP/SDP headers, replacing private addresses with public ones for both signaling and media.

SBC Architecture (RFC 7092)

SBCs operate at multiple levels:

• Proxy-B2BUA: Only modifies Via/Record-Route; can generate BYE for dead sessions
• Media Relay B2BUA: Forwards RTP without inspection; modifies IP/UDP headers only
• Media-Aware B2BUA: Inspects/modifies RTP headers and RTCP; does not touch codec payload
• Media-Termination B2BUA: Full termination — transcodes, records, modifies everything

Topology hiding: SBCs strip all incoming Via headers, generate new Call-ID between legs, replace Contact URI, modify Record-Route headers, and anonymize SDP. For SRTP, the SBC acts as a DTLS endpoint on each leg separately — generating its own certificates per leg in media-termination mode, or passing fingerprints through in media-relay mode.

Self-Hosted VoIP Platforms

Self-hosted VoIP platforms run on the organization's own server — physical or virtual — in a data center, office server room, or private cloud (AWS, DigitalOcean, Azure). This provides total control over data, call routing, and trunking configuration.

Asterisk Architecture

Asterisk is the open-source industry standard telephony engine, created by Mark Spencer in 1999. Its architecture is based on:

• Channel Drivers: Implement the ast_channel_tech interface; handle protocol-specific signaling (PJSIP for SIP, DAHDI for TDM, IAX2, etc.)
• Dialplan: extensions.conf (or AEL/LUA); sequential priority-based routing compiled to memory at startup
• Applications: Playback(), Dial(),Voicemail(), Queue() — invoked from dialplan
• Bridging: Connects two or more channels for media exchange

API interfaces: AGI (Asterisk Gateway Interface) — synchronous stdin/stdout scripting, forks OS process per call. AMI (Asterisk Manager Interface) — persistent TCP for monitoring and control. ARI(Asterisk REST Interface, introduced 2013) — REST + WebSocket, async event-driven model for modern applications. Each inbound channel gets its own thread executing the dialplan. Scalability: 300–3,000 concurrent calls per server depending on hardware and transcoding load.

FreeSWITCH Architecture

FreeSWITCH (created 2011 by Anthony Minessale) is a multi-threaded, event-driven telephony engine designed as a higher-performance alternative to Asterisk. It uses the Sofia-SIP stack (full RFC 3261 compliance) and anXML dialplan compiled to an in-memory regex tree. The Event Socket Layer (ESL)provides a push-based async event stream over TCP — more efficient than Asterisk's AGI (which forks a process per call). FreeSWITCH has native WebRTC support via mod_verto (WebSocket signaling, DTLS-SRTP media). Scalability: 3,000–20,000+ concurrent calls per node.

┌────────────┬───────────────┬──────────────────┐
│ Aspect │ Asterisk │ FreeSWITCH │
├────────────┼───────────────┼──────────────────┤
│ Model │ Monolithic │ Multi-threaded │
│ Concurrency│ 300–3,000 │ 3,000–20,000+ │
│ Dialplan │ extensions.conf│ XML (regex) │
│ Integration│ AGI/AMI/ARI │ ESL (push-based) │
│ WebRTC │ Add-on │ Native (mod_verto)│
│ TDM │ Excellent │ Limited │
└────────────┴───────────────┴──────────────────┘

FreePBX

FreePBX is a web-based GUI that manages Asterisk, providing a graphical interface for provisioning extensions, trunks, ring groups, IVR menus, queues, and call recording. It eliminates the need to manually edit extensions.confor pjsip.conf. FreePBX has no per-user licensing fees and supports thousands of third-party modules. Available as a standalone distribution (Debian) or as Sangoma's commercial UC Edition appliance.

3CX

3CX is a commercial software PBX that runs on Windows or Linux (Debian). It includes integrated video conferencing (based on WebRTC), live chat, mobile apps (iOS/Android), and Microsoft Teams integration. Pricing is based onconcurrent calls rather than per-user seats — a business with 500 extensions but only 50 simultaneous calls pays for 50-call licensing. Includes built-in SBC, auto-provisioning for major phone brands, and a management console. Free edition available for up to 10 extensions.

Issabel

Issabel is an open-source PBX platform built on Asterisk, emerging from the legacy Elastix project. Elastix (by PaloSanto Solutions) was acquired by 3CX in 2019; the community fork became Issabel. It bundles voice calls, video, email, and instant messaging into a single interface, with an integrated call center module (ACD, queues, real-time dashboards) and built-in security features (fail2ban integration, intrusion detection).

FusionPBX

FusionPBX is a multi-tenant administrative web interface built onFreeSWITCH. It provides isolated contexts, dialplans, and user databases per tenant — designed for service providers and large enterprises. FusionPBX leverages FreeSWITCH's superior scalability (1,000–5,000+ concurrent calls per node) and native WebRTC support, making it a carrier-grade alternative to Asterisk-based systems. PHP-based web interface; less mature than FreePBX but handles higher call volumes.

Yeastar P-Series and Grandstream UCM6300

Yeastar P-Series unites voice, video, omnichannel messaging (SMS, WhatsApp, live chat), and CRM integrations in both cloud and on-premises environments. It supports a browser-based softphone (Linkus) and call center features (queues, dashboards, recording). Grandstream UCM6300 Series is a self-contained appliance supporting up to thousands of users with built-in video meetings, Wave app connectivity, and auto-provisioning — no recurring licensing fees, making it attractive for businesses preferring CapEx over OpEx models.

Cloud PBX — RingCentral, Vonage, Zoom Phone, Teams Phone

Cloud PBX (UCaaS) moves the PBX entirely to the provider's data center. The enterprise provides internet connectivity and IP phones; the provider handles call routing, voicemail, IVR, ACD, and all features. Economics: typically $20–$40 per user per month. The trade-off is dependence on internet quality — VoIP requires low latency (<150 ms), low jitter (<30 ms), and minimal packet loss (<1%) for acceptable quality.

• RingCentral: Enterprise UCaaS with video, messaging, global SIP trunking. Up to 10,000 users.
• Vonage: SMB-focused with API integrations for CRM and custom workflows.
• Zoom Phone: Integrated with Zoom video; proprietary Zoom-to-Zoom protocol, SIP for PSTN.
• Microsoft Teams Phone: Cloud PBX in Teams; 300M+ monthly active users. Calling plans, direct routing via SBCs, operator connect.

PSTN Gateways and the Hybrid World

VoIP does not exist in isolation — millions of legacy telephones, fax machines, and alarm systems still connect to the PSTN. PSTN gateways bridge VoIP and circuit-switched networks, handling: codec transcoding (G.711 ↔ G.729/Opus), signaling translation (SIP ↔ SS7/ISUP), DTMF relay (RFC 4733 in-band ↔ out-of-band SS7), fax relay (T.38 — packetized fax over IP), and emergency call routing (E911 — mapping VoIP caller to physical location).

The FCC's 2022 order (Order 22-86) allowing carriers to retire copper PSTN infrastructure is accelerating the transition to all-IP networks. By 2028, major US carriers plan to discontinue POTS service, making PSTN gateways essential for legacy device compatibility during the migration period.