A VoIP gateway connects a telephone interface to an IP calling system. Choose one by identifying what is attached to each side: an analog phone, a telephone line, a digital PBX circuit or a SIP service. That interface inventory determines whether a small ATA, a multiport analog gateway or a digital gateway fits the job.
Start with the direction of the telephone interface
An FXS port supplies an analog telephone interface, including line feed and ringing, to a phone. An FXO port connects to a line supplied by a telephone service or an appropriate PBX analog extension. Match the electrical role as well as the connector shape. Cisco’s analog-port explanation describes these signaling roles.
Two different paths
Analog phone ⇄ gateway FXS port ⇄ IP network ⇄ calling service
Existing analog line ⇄ gateway FXO port ⇄ IP network ⇄ PBX
These are interface diagrams. Installation follows the specific device manual and the site’s wiring plan. Do not connect an FXS output to a live telephone-company line.
As a concrete hardware example, Grandstream’s HT813 installation guide identifies one FXS port for an analog phone and one FXO port for a PSTN line. The shared RJ11 shape does not make those ports interchangeable. This example illustrates port roles, not a product recommendation.
Swipe horizontally, or focus the table and use the arrow keys.
| What you are connecting | Typical gateway requirement | Evidence to obtain |
|---|---|---|
| One analog desk phone | ATA with an FXS port | Phone type, ringing load, service support. |
| Several independent analog extensions | Multiport FXS gateway | Required ports, extension mapping, simultaneous calls. |
| An existing analog service line | FXO interface | Provider signaling, caller ID and disconnect behavior. |
| PBX digital trunk | Matching digital gateway | Exact T1/E1/BRI interface, signaling, clocking and channel plan. |
| SIP PBX to SIP carrier | Supported IP interconnection; possibly an SBC | Provider topology, interoperability and security requirements. |
ATA usually describes a compact analog telephone adapter. Gateway is the broader category; a product can also include routing functions. Decide from its documented interfaces and supported call paths. The SBC guide covers the IP-to-IP boundary. Our 2004 digital-gateway article is historical product coverage, rather than a current compatibility guide.
Make a compatibility inventory before ordering
Photograph equipment labels and record the manufacturer, model, firmware, connector and purpose of every attached device. A socket marked “phone” on an old PBX can serve a proprietary digital handset. Obtain its manual before classifying it as analog. Keep credentials out of the inventory.
- Ports and calls: count independent extensions and simultaneous conversations separately. Several handsets sharing one analog line are one line arrangement, with ringing-load limits to check.
- Regional behavior: record country, caller-ID format, tones, impedance and the method used to recognize hang-up.
- Special devices: identify fax machines, door systems, alarms, elevator phones, payment terminals and modems. Ask the device maintainer and service provider for explicit support and an approved test procedure.
- Operating dependencies: list gateway power, network equipment, internet access and the people responsible for each.
The HT813 administration guide demonstrates why these details matter: it documents model-specific ringing load, termination settings, disconnect methods and fax modes. Its limits belong to that device. Read the corresponding specifications for the exact candidate and firmware you intend to deploy.
Worked example: a small reception area
Fictional starting point: a site has two independent analog desk phones and one fax machine. Both phones must support simultaneous conversations. The fax must receive while the phones are busy. There is no analog carrier line to retain.
The initial requirement is three FXS ports and a service/gateway combination supporting the required three simultaneous sessions, including the fax method. An FXO port adds no required function in this example. A two-port ATA leaves one device without an interface.
Before selecting hardware, the team asks whether the fax can move to an approved service workflow. If that change meets the business requirement, the physical inventory becomes two FXS ports. Record the decision and test the resulting workflow, including receiving and retrieving documents.
For an on-site fax, agree on T.38 or the provider’s supported audio pass-through configuration at every relevant boundary. A gateway’s fax feature alone cannot establish end-to-end compatibility. Test representative incoming and outgoing documents with the actual remote destinations; retain page-count and legibility results.
Confirm both ends of the service connection
Ask the provider for the exact supported model and firmware, authentication arrangement, provisioning method, codec and DTMF requirements, network rules and support ownership. A successful SIP registration is only the first checkpoint; inbound routing, outbound identity, voicemail and keypad interaction need separate tests.
For example, Microsoft publishes a Teams SIP Gateway device and firmware planning list. A device’s general SIP capability does not by itself place it on that platform’s supported list. Preserve a dated copy or reference to the provider’s compatibility evidence in the procurement record.
Have the administrator apply supported firmware, unique administrative credentials, controlled management access and the provider’s provisioning profile. Agree how configurations are backed up and recovered. Avoid exposing the administration interface to the public internet as a shortcut to remote support.
Document loss-of-power and loss-of-internet behavior separately. A relay feature requires a functioning alternate line and compatible wiring to provide a usable route; many installations have no such line. Use the home-phone dependency and outage guide or business migration plan to include emergency location and alternate calling arrangements.
Accept the complete call path
- Check identity and routing. Call each extension from outside and call out to an agreed test number. Verify the intended phone rings and the expected caller ID appears.
- Check conversation and control. Listen in both directions, enter digits into an authorized test menu, and exercise hold or transfer where required. Confirm hang-up releases the line.
- Apply the planned load. Place simultaneous calls on the required ports. Check ringing on idle devices during that load. Run the agreed special-device tests separately.
- Test recovery in a scheduled window. Use the administrator’s outage and restoration plan. Observe registration, routing and alert recovery. Use provider-approved emergency-service verification procedures; do not place casual emergency test calls.
- Record the result. Save timestamps, device and firmware versions, port mappings, expected/actual behavior and support references. Resolve a failed requirement before accepting the installation.
Download the gateway inventory and acceptance worksheet. It includes the reception example and fields for recording the actual configuration, evidence and unresolved gaps.