ALPHA Telecom reading
Countries

Reference / Voice

FXO interfaces for a PBX: an integration checklist

An FXO interface receives an analogue telephone line; an FXS interface supplies the line to a telephone or fax machine. Choosing the correct electrical role comes before choosing a PBX driver, expansion card or gateway.

Connect the telephone roles: Telephone → FXS interface → Voice gateway → IP service
Connect the telephone roles An illustrative analogue-phone-to-IP path: the telephone faces an FXS interface. This is a role diagram, not a promise that any named old device supports the required service.

Distinguish FXO and FXS

The FXS side provides line power, dial tone and ringing. The FXO side receives the line and signals when it goes on or off hook. An analogue telephone is on the receiving side; a PBX port accepting an outside analogue line also needs the receiving role.

Draw the path from telephone through PBX to the external circuit and label each port from the exact equipment documentation. Record regional line characteristics, connector type, caller-ID method, dialling and disconnect behaviour. Do not infer an electrical interface solely from a driver configuration label.

Commission in stages

Use a test line or approved maintenance window. Verify ringing, outbound dialling, two-way audio, disconnect recognition and recovery. Test voicemail or routing only after basic line behaviour is stable.

For IP media, verify DTMF deliberately. Telephone events may need a defined method instead of relying on a voice codec to reproduce tones. Claim compatibility only after testing the exact hardware, driver and service together.

Protect the live circuit

Telephone circuits can carry operational or emergency traffic. Identify the owner, maintenance window and rollback point before moving a line. Never treat an unplugged line as a harmless lab input.

Document how a user reaches assistance if the PBX, gateway or power fails. This is an operational requirement, not a feature claim about a particular card.

Identify the electrical role before the PBX role

FXS and FXO describe opposite ends of an analogue service. The FXS side supplies dial tone, line power and ringing; the FXO side receives the line and signals on-hook or off-hook. A label in a PBX screen does not reverse that electrical relationship. Start a design by drawing the actual pair: wall service or gateway on the supplying side, and the telephone, fax, gateway or PBX port on the receiving side as applicable.

That drawing prevents a costly category error. “Connect the analogue line to the PBX” is incomplete until the receiving interface is named. A second drawing should show the call direction separately from the copper pair: a caller may enter through an FXO interface while the PBX later selects an extension, an application or an IP route. Electrical attachment and call routing are coupled in service, but they fail for different reasons and should not share one vague test.

Turn a line into observable state changes

Commission an analogue path as a sequence rather than a single call. For an outbound attempt, observe line seizure or off-hook indication, receipt of dial tone where that is expected, digit delivery, progress and answer. For an inbound attempt, observe the incoming ring indication, answer transition, two-way speech and final release. Record which end was expected to detect each transition. This makes a one-way fault traceable instead of merely inconvenient.

A useful example is a call that connects but remains held after both parties hang up. Do not begin by rewriting the dial plan. First identify whether the analogue interface still reports an active condition, whether the PBX still owns the channel, or whether the IP leg has remained in its session. The remedy differs for each observation. The trade-off is a few deliberate checks before cutover versus a live circuit whose failure state cannot be explained.

Map the PBX channel without inventing compatibility

A DAHDI channel property is an interface to a channel, and some documented properties apply only on FXO-signalled channels. That is a useful boundary, not a promise that any old card, driver, line or service will work together. Keep four identifiers together in the test record: the physical port, the operating-system channel, the PBX channel designation and the dial-plan entry point. If one changes, a successful call can otherwise be attributed to the wrong path.

Use the smallest configuration that can prove the mapping. Route one authorised test extension through one named channel to one approved destination, then reverse the direction. Add caller treatment, menus and alternative routes only after that basic pair is understood. This reduces blast radius and gives a failed call a clear ownership path: physical interface, channel mapping, call-control rule or the far end.

Treat DTMF as a separate media requirement

Digits can be audible to a person and still be unusable to an automated receiver. RFC 4733 defines RTP payloads for DTMF and other telephony events because low-rate voice codecs cannot be assumed to reproduce tones accurately enough for automatic recognition. Therefore a call with clean speech is not evidence that a menu, voicemail system or remote control function will receive digits correctly.

Test the exact direction and exact target that matter. Make a short authorised call, enter a sequence with distinct digits, and confirm the application received each intended action rather than merely that the caller heard tones. Then test the reverse direction if a gateway converts events back to an analogue path. A mismatch can arise at the event method, the negotiated media description or the gateway boundary; changing extension routing cannot establish which one.

Use symptom shape to choose the next check

No dial tone points first to the service-supplying side, cabling, port role or an off-hook transition; it says little about an IP route. Ringing with no answer indication directs attention to the receiving side and its detection. Speech in only one direction moves the investigation to the media legs after call establishment. A call that will not clear is a release-state question. These are working classifications, not conclusions, and each should be confirmed at the named interface.

Avoid compensating for an unknown cause with extra timers, retries or permissive routing. Such changes can hide the original symptom while creating a second failure mode. Instead preserve the call time and channel identity, reproduce once under controlled conditions, and compare it with a known-good path. The comparison is especially valuable with legacy interfaces because configuration names alone do not prove the electrical condition at the connector.

Protect the service while testing the conversion

An analogue circuit may carry operational or emergency traffic, so a conversion test needs a defined isolation point. Before moving a live line, decide which physical reconnection restores the previous path, who may make it, and how users reach assistance if the PBX, gateway or power path is unavailable. This is architecture, not paperwork: the rollback path determines whether a fault can be contained without improvising around a telephone service.

Test the recovery path with the same care as the preferred path. A gateway that accepts a first call but does not recover cleanly after a power interruption is not ready for unattended use. The deliverable of the exercise is a bounded understanding of one actual line path and its faults, not a general claim about a particular expansion card.