Skip to main content

PSTN-to-SIP gateway architecture with Asterisk

A PSTN-to-SIP gateway lets an IP PBX such as Asterisk use a conventional analog telephone line without putting an analog interface card directly inside the PBX server.

The gateway terminates the analog line through an FXO interface, converts the audio and exposes the call across the LAN as SIP/RTP. From the PBX perspective, the gateway can then behave like a SIP trunk or peer.

PSTN to SIP gateway architecture showing an analog PSTN line entering an FXO gateway and a SIP/RTP connection to Asterisk or FreePBX

Basic architecture​

Separating the analog hardware from the PBX can be attractive for compact appliances, remote sites, hardware-isolation requirements or systems where the PBX runs in a VM/container but the analog line is physically elsewhere.

Inbound call flow​

For an inbound PSTN call, a simplified sequence is:

  1. the telephone network applies ringing to the analog line;
  2. the FXO interface detects the ring;
  3. the gateway waits as required for caller-ID timing;
  4. the gateway creates a SIP INVITE toward Asterisk;
  5. Asterisk applies its dialplan and chooses an extension, ring group, IVR or application;
  6. when the SIP side answers, the gateway seizes the analog line if it has not already done so;
  7. audio flows between the analog interface and RTP session;
  8. hangup/disconnect supervision tears down the SIP session.

The exact point at which the FXO line is seized depends on the caller-ID method and desired call behavior.

Outbound call flow​

For an outbound call:

  1. an Asterisk dialplan selects the FXO gateway trunk;
  2. Asterisk sends a SIP INVITE containing the destination number;
  3. the gateway selects an available FXO port;
  4. the gateway seizes the line and waits for the appropriate dial condition;
  5. digits are sent to the PSTN using the configured method;
  6. the gateway detects call progress/answer according to its capabilities and regional setup;
  7. RTP media is bridged to the analog audio path.

This is why an FXO gateway needs more than a simple ADC/DAC: it must understand the state of the analog line.

Asterisk/PJSIP integration model​

Modern Asterisk deployments commonly use PJSIP configuration. The gateway can be represented as an IP endpoint/trunk whose address, authentication and routing rules are defined in the PBX.

On the gateway side, configuration typically includes:

  • PBX IP address or hostname;
  • SIP port/transport;
  • account or trunk identity;
  • registration mode if used;
  • codec/media parameters;
  • per-FXO-port dialing rules;
  • caller-ID and regional line settings.

The IRIS4000 getting-started guide documents the original ZMATRIX integration with Asterisk/FreePBX using a PJSIP trunk model. Menu names and configuration details can differ on newer PBX releases, but the underlying architecture remains the same.

Caller ID and ringing​

Caller-ID delivery is one of the main reasons a real analog gateway needs country/carrier-specific configuration.

If the gateway answers or seizes the line before caller-ID information has been delivered, the PBX may see the call but lose the caller identity. The firmware may therefore need to wait for a particular ring interval or signaling event before presenting the call to SIP.

Disconnect supervision​

Detecting that the PSTN caller has hung up can depend on the local line service. Possible mechanisms include:

  • current interruption;
  • polarity reversal;
  • tone detection;
  • timeout;
  • provider-specific supervision behavior.

If disconnect supervision is configured incorrectly, a SIP call can remain active after the remote analog party has already disconnected.

NAT is usually unnecessary on a local gateway​

When the FXO gateway and Asterisk server are on the same routed LAN, NAT traversal should generally not be part of the design. Keeping the gateway on a stable local address simplifies SIP signaling and RTP media routing.

If the gateway is at a remote site, use a controlled routed/VPN architecture rather than exposing an unauthenticated SIP endpoint directly to the public Internet.

Security considerations​

Legacy analog lines do not make the IP side safe. The SIP gateway should still follow normal network-security practices:

  • restrict SIP access to the intended PBX or management network;
  • use strong credentials where authentication is used;
  • avoid unnecessary public exposure;
  • protect management interfaces;
  • segment the device appropriately;
  • keep firmware and PBX software updated.

Where SIP over TLS or SRTP is required, confirm that both gateway and PBX configurations are compatible and that certificate/key handling is operationally manageable.

IRIS4000 example​

IRIS4000 combines two FXO interfaces with an Orange Pi Zero host and ZMATRIX SIP firmware. It was designed for exactly this class of compact PSTN-to-SIP integration and has been used with Asterisk/FreePBX.

ZMATRIX has limited remaining assembled inventory. For longer-lifecycle or higher-volume new designs, the same architecture can be migrated to a newer embedded platform or adapted into custom hardware.