IP PBX Systems — five on-premise models from 24 to 1000 SIP trunks

An IP PBX is a telephone system whose extensions and outside lines are IP: phones register to it over SIP, calls are routed in software, and the features (auto attendant, ring groups, voicemail, recording, call records) run on the same platform. In this range it is an appliance on the local network — five models from 24 to 1000 SIP trunks.

• Extensions: SIP desk phones, hotel handsets, care stations, consoles, door phones, speakers and softphones all register as extensions.
• Outside lines: SIP trunks over the internet, or analog lines terminated on FXO ports.
• Analogue endpoints: FXS ports keep a fax machine, an analog phone or a legacy door entry in service.
• Management: web GUI or SSH locally and remotely, with TR069 central provisioning.

A maximum number of IP extensions is not stated for any model in the published documentation, and we do not invent one. What is published is the SIP trunk capacity — 24, 62, 216, 496 and 1000 across the five models — plus the concurrent-call ceiling per trunk, 120 or 200.

• Register more extensions than you have trunks: extensions are internal, trunks are outside lines. The published ceiling per trunk is what limits simultaneous outside calls.
• Ring groups hold 40 extensions on the OM20G and OM50G and 60 on the larger models, which is a practical limit when designing a group that must ring several positions at once.
• Send the extension count and the busy-hour call count and the model is confirmed on the quotation, rather than sized from a table on a website.

A SIP trunk is an outside line delivered over IP instead of a copper pair: the provider gives you a number (or a block of numbers) and a registration or an IP peer, and the PBX treats it as a trunk. You need one — or several — if you want calls to and from the outside world, unless you keep analog lines on FXO ports.

• One trunk carries up to 120 concurrent calls, 200 on the OM1000-UC; how many you need depends on the busy-hour call count, not on the headcount.
• Direct-inward-dialling (DID) binds an outside number to an extension or a group so callers bypass the auto attendant; on the OM1000-UC, DID/DOD binds up to 4 outside numbers to one extension or group.
• Where analog lines remain, they can be kept on FXO ports and outbound SIP calls can be set to fall back to them when the trunk fails.

They solve different problems. The OM series is on-premise hardware: the call-routing core sits in your building, which keeps internal calls working when the internet does not, gives you the analog ports, and avoids a monthly platform charge. A hosted PBX is a service in which the core runs in a data centre and the phones register to it over the internet.

• Choose on-premise when continuity of internal calls, analog lines, local recording and site-controlled data all matter — hotels, hospitals, factories and campuses usually land here.
• Choose hosted when the site is small, has no equipment room, and every extension has a reliable internet connection; the terminals in this range register to third-party SIP platforms as well.
• A hybrid is common: an on-premise PBX for the site and its trunks, with remote extensions registering over the internet through the published remote-access options.
• NEXVIA supplies and commissions on-premise systems; a hosted platform would be supplied by its own service provider, and the terminals stay the same.

Yes, on every model except the OM1000-UC. Analog ports are 4 on the OM20G (4 FXS, 4 FXO or 2+2), up to 12 on the OM50G, up to 48 on the OM80E and up to 96 on the OM200G, ordered as FXS, FXO or a mix.

• FXO ports take an outside analog line; FXS ports take an analog phone, a fax machine or a legacy door entry.
• Fax runs as T.38 or G.711 pass-through, with G.711 pass-through required over an analog line and a maximum transmission speed of 33600 bps.
• The OM1000-UC has no FXS or FXO ports at all, so a site that must keep analog devices should plan the OM200G or keep a smaller PBX as the analog gateway.

The published behaviour is specific. The OM1000-UC supports dual hot standby between two paired units with 3 fixed IP addresses and a 10-second health heartbeat; ETH1 and ETH2 can run as a redundant pair with a switchover in about 1.75 seconds; a backup SIP server can be configured by fixed address or DNS SRV.

• Analog lines on FXO ports keep working directly during an internet outage, and an outbound SIP call can fall back to an analog line automatically.
• The OM20G can dial out through a 3G/4G USB modem where no wired line exists.
• Recording and voicemail storage sit on the internal storage (16 GB on the first four models, a 32 GB SD card on the OM1000-UC), and storage can be backed up to a USB device.
• Plan the redundant path deliberately: a second uplink, a second PBX or an analog fallback is a design decision made before the first outage.

Four steps: set the PBX address on the network, create the extensions (in batches), let the phones provision themselves over DHCP option 66 or TR069, and then configure the trunks, dial plan, groups and recording. The published setup guide creates extension blocks of ten, for example 101–110, and phones pick up configuration without a visit.

• Extensions are numbered from 200 by default on the PBX ports, and IP extensions can use any numbering scheme the site prefers.
• Auto provisioning supports TFTP, FTP, HTTP and HTTPS, with TR069 for central management and a firmware update cycle on power-up or on a periodic schedule.
• Plan the firewall for remote extensions: SIP signalling on 5060 by default, and the RTP range 10010–10266, where each call uses an RTP and an RTCP port.
• NEXVIA commissions the system on site and hands over the dial plan, extension list and configuration export.

The platform ships with the controls that stop the usual attacks, and they should be configured rather than left at defaults: an access whitelist of up to 20 addresses, static ACL rules, dynamic rate limiting, and an account lock-out after a configurable number of failed logins (1 to 6 per day, default 6, locked for 10 minutes by default).

• Signalling and media can be encrypted: TLS for SIP registration and SRTP for the media, with several negotiation modes published, plus a voice-packet encryption setting and T.38 data encryption.
• Two management levels (administrator and operator) with a read-only browsing mode; SSH is disabled by default and the web interface runs on HTTPS (port 443 by default, HTTP 80 redirects to it).
• Alarm classes include security notices, orange alarms and red alarms, with red covering trunk registration failure, extension registration failure, DNS failure, port disconnection and SIP attacks.
• For extensions registering from outside, use TLS and SRTP, restrict the source addresses and review the security level setting, which can refuse registrations from outside on high or medium.