Huawei eSpace Alternative: Replacing eSpace Without Breaking the IMS Layer

The hardest part of replacing an eSpace or U19 deployment is rarely the phone system itself. It is the IMS layer. Carrier IMS networks are not "SIP with extra steps" — they use different addressing, different registration models and different number plans, and a platform that treats IMS as an afterthought will struggle with exactly the trunk that matters.

Definition: A Huawei eSpace alternative is a business voice platform that replaces Huawei eSpace or U19 deployments while carrying the IMS, ISDN PRI, SIP trunking and endpoint requirements the existing estate depends on.

What eSpace deployments usually run on

Huawei's enterprise voice portfolio covers a wide range of estates, and the ones worth planning against typically combine:

• An eSpace or U19 core handling extensions, calling plans, IVR, voicemail and hunt groups.
• Carrier connectivity that is often IMS, sometimes ISDN PRI, sometimes a mix — the same carrier may deliver SIP to one site and PRI to another.
• Huawei and third-party SIP endpoints, plus a legacy layer of analogue devices on FXS ports: fax machines, intercoms, alarm panels and older desk phones.
• Local survivability at branch sites, typically via a distributed component so a WAN cut does not kill a remote location.
• Recording and call accounting, frequently deployed as separate systems bolted onto the core rather than natively.

Getting this list right matters because it determines which of the two migration routes below applies to you.

The IMS layer: SIP-to-IMS conversion explained

Where a carrier offers IMS rather than plain SIP, a business needs something that can translate between the two. A device that speaks SIP end to end will often register fine in the lab and then fail against a live IMS core, because IMS registration involves identifiers, authentication and routing that plain SIP does not model.

Newrock builds IMS handling into the platform rather than bolting it on:

• The MX60E-G-SC is a VoIP gateway with 48 FXS ports, 48 SIP/IMS registration accounts, 32 concurrent calls on G.711 and 16 on G.729A with G.711, compatibility with mainstream operator IMS platforms, and T.38 V3 high-speed fax support. The IMS compatibility is a stated product capability, not a "should work" assumption.
• The OM1000-TE performs IMS/SIP and ISDN PRI (30B+D) protocol conversion, supports up to 120 concurrent calls, up to 40K busy-hour call capacity, 500 routing and number transformation rules, up to 512 SIP trunk accounts, and provides dual network port and dual power supply redundancy with 6000MIPS DSP processing capacity.
• The SX100 session border controller supports SIP/IMS access, codec conversion across G.711 (A-Law and U-Law), G.723.1, G.729a/b, iLBC, G.722, G.722.1, G.722.2, AMR, H.264 and H.265, customisable signalling header fields, protocol conversion and DTMF mode conversion, with 1000 user registrations, 120 concurrent sessions and 70 media transcoding channels.

The practical value of these three is that IMS, PRI and SIP are handled as native protocol tasks rather than as things a gateway handles badly. For a business with carrier IMS connectivity, that is the difference between a two-week project and an open-ended one.

How PRI and 30B+D trunking fits the migration

ISDN PRI (30B+D) remains common on legacy estates because it is what carriers historically delivered to PBXs, and it is what a lot of old international PBX infrastructure still runs on. Migrating away from Huawei often means migrating away from PRI at the same time, or keeping it during a transition.

Newrock handles both directions. The OM1000-TE does the ISDN PRI (30B+D) side of the conversion with up to 120 concurrent calls and 500 routing and number transformation rules — the routing rules count is what makes a complex legacy numbering plan migratable rather than a manual re-entry project. The SX100 supports ISDN and SIP trunks with trunk redundancy and load balancing, so a site can carry PRI, SIP and IMS simultaneously during a phased migration.

For an estate with many PRI channels, the MX60E-G-SC's combination of IMS registration accounts and concurrent call capacity is the relevant number, and it should be checked against actual busy-hour traffic rather than against channel counts.

Operator IMS platform compatibility considerations

The OM series publishes capacity figures for every model, which makes the sizing conversation concrete.

When you are replacing a platform whose IMS layer was integrated by the carrier or by a local integrator, four things need verification before you commit to a design:

1. Registration identity. Confirm whether each site registers as a single account or per-endpoint, and whether the replacement platform supports that model. The MX60E-G-SC supports 48 SIP/IMS registration accounts and the OM1000-TE registers up to 512 SIP trunk accounts, so most registration topologies fit — but the topology itself has to be decided deliberately rather than inherited by accident.
2. Number plan translation. IMS numbering often does not match your internal extension numbering. This is what the 500 routing and number transformation rules on the OM1000-TE are for, and it is the area where a migration either looks painless or becomes a month of translation tables.
3. Codec negotiation. IMS networks may offer a narrower codec set than plain SIP. The SX100's codec conversion and 70 media transcoding channels are relevant here, and so are its protocol and DTMF mode conversion features, which affect how in-band tones survive a translation layer.
4. Fax and legacy device behaviour. If any branch still sends fax over IMS, check for T.38 support. The MX60E-G-SC provides T.38 V3 high-speed fax, which is the concrete requirement here.

A practical eSpace-to-IP-PBX migration path

A sequence that has held up across similar estates:

1. Map the IMS topology. Which sites are IMS, which are PRI, which are plain SIP. Get this in writing from the carrier — do not assume consistency.
2. Confirm the endpoint estate. Huawei SIP phones will generally register with an OM-series platform. Newrock's own NRP range covers the common cases: the NRP1312G/P with 4 SIP lines, 2.8-inch colour screen, HD voice, PoE, 1000-entry local and remote phonebooks, 600 call records, black and white lists, caller ID and VMWI; the NRP2020/W WiFi phone with 6 SIP accounts, 13 programmable keys and 400 call records; the NRP1600/P video phone with 10 concurrent calls and up to 140 soft DSS keys; and the NRP1610G/P Android handset with a 7-inch 1024x600 touchscreen, 20 SIP lines, 112 DSS keys, video call reception, PoE, WiFi and Bluetooth, a 2000-entry local directory and support for third-party applications and API-based customisation.
3. Build the new platform alongside the old. The OM series supports head-office and branch SIP trunk communication, which makes a parallel-running period straightforward.
4. Move one site and one trunk type first. Prove the IMS registration and the number translation on a single branch before touching the rest of the estate.
5. Move extensions in batches by area. Not by person. Batch migration by floor or site produces far less support load.
6. Rebuild calling plans deliberately. Hunt groups, overflow, direct-dial entry points and recording rules get re-created and tested, not imported by default.
7. Cut recording and CDR over last. RMS collects, stores, plays back and manages recordings from OM series and MX series platforms; Recording Agent runs on Windows and stores OM recordings as MP3; CDR Software collects call detail records as .txt to an external server for management and retrieval.
8. Keep the old trunks alive through a full business cycle. Including a month-end and a pay run.

Newrock perspective

Newrock's position on eSpace replacement is that the IMS layer is the project. Everything else — endpoints, calling plans, recording — follows a familiar path. The differentiator is a product line that treats IMS, PRI and SIP as native protocol work.

That means the MX60E-G-SC for IMS-connected branches, with 48 FXS ports, 48 SIP/IMS registration accounts, 32 concurrent calls on G.711 and 16 on G.729A with G.711, mainstream operator IMS platform compatibility and T.38 V3 high-speed fax. The OM1000-TE for enterprises that need IMS/SIP to ISDN PRI (30B+D) conversion with up to 120 concurrent calls, up to 40K busy-hour call capacity, 500 routing and number transformation rules, 512 SIP trunk accounts, dual network port and dual power supply redundancy and 6000MIPS DSP processing capacity. The SX100 for enterprises that need a controlled SIP/IMS border with 1000 user registrations, 120 concurrent sessions, 70 media transcoding channels, customisable signalling header fields, codec and protocol conversion, DTMF mode conversion, call recording, voice quality monitoring, and trunk redundancy and load balancing.

On the platform side, the OM series covers 54 to 10000 users, with the OM20G as the compact all-in-one and the OM8000 at the top of the range. For multi-site estates, UMS provides the single management and remote maintenance console across OM series and MX series, the MA50-LS local survivability branch exchange keeps branches serving calls with 2 to 8 FXO ports and 50 to 200 SIP registrations when the head office is unreachable, and the MA50-LS switches back automatically once the connection returns.

The MX60E-G-SC gateway, OM1000-TE media gateway and SX100 session border controller pages are the ones to read.

FAQ

Can we keep our Huawei SIP phones?

Huawei SIP phones are SIP endpoints, so they will generally register with an OM-series platform. Features that depend on Huawei-specific provisioning will not carry over, so verify model by model rather than assuming compatibility in either direction.

What is the hardest part of an eSpace migration?

Almost always the IMS layer and the number plan that sits on top of it. Where the carrier delivers IMS rather than plain SIP, registration identity and number translation have to be designed rather than imported. That is why the OM1000-TE's 500 routing and number transformation rules and the MX60E-G-SC's 48 SIP/IMS registration accounts are the numbers to look at first.

Does Newrock support ISDN PRI?

Yes. The OM1000-TE performs IMS/SIP and ISDN PRI (30B+D) protocol conversion with up to 120 concurrent calls, up to 40K busy-hour call capacity and 500 routing and number transformation rules. The SX100 also supports ISDN and SIP trunks with trunk redundancy and load balancing, which allows PRI, SIP and IMS to run in parallel during a phased migration.

Can the new system run beside the old one?

Yes. The OM series supports head-office and branch SIP trunk communication, and the SX100 supports branch networking and cross-network interconnection. A parallel-running period is the recommended approach for a controlled cutover.

What about our branch offices?

Two things are needed: trunking between sites, and a defined behaviour when the WAN fails. The OM series handles head-office and branch SIP trunk communication, and the MA50-LS local survivability branch exchange keeps a branch serving calls locally when the head office or cloud server is unreachable — with 2 to 8 FXO ports, 50 to 200 SIP user registrations, and automatic switch-back to the central server once the connection returns.

How do we handle recording and call accounting?

As separate, retrievable components rather than a closed reporting tool. RMS collects, stores, plays back and manages recording files from OM series and MX series platforms. Recording Agent runs on Windows and stores OM recordings as MP3. CDR Software collects call detail records as .txt files to an external server and manages and retrieves them.

Does the new platform still support our analogue devices?

Yes, and the built-in analogue ports make this easier than it sounds. The OM20G carries up to 4 built-in FXS/FXO ports, the OM50G up to 12, the OM80E up to 48 and the OM200G up to 96. A separate MX-series gateway is only needed where the analogue population is too large for the built-in ports or needs to operate independently of the PBX.

How long does the whole thing take?

The physical work is fast. The elapsed time is carrier provisioning for IMS and PRI trunks, number porting, number plan translation, calling plan reconstruction and user retraining. In a mid-sized estate, plan on weeks. Carrier IMS provisioning is often the long pole — get that confirmation early.

Conclusion

An eSpace replacement is an IMS project before it is a phone project. Map which sites are IMS, which are PRI and which are plain SIP, and get that in writing from the carrier before you design anything. Then choose the component that carries the IMS layer natively — the MX60E-G-SC for IMS-connected branches with its 48 SIP/IMS registration accounts and operator IMS platform compatibility, the OM1000-TE for IMS/SIP to ISDN PRI (30B+D) conversion with 500 routing and number transformation rules, or the SX100 for a controlled border with codec and protocol conversion. Build the new platform in parallel, prove one site and one trunk type, move extensions in batches by area, rebuild calling plans deliberately, cut recording and CDR over last, and keep the old trunks alive through a full business cycle. The rest — endpoints, recording, multi-site management — follows a well-trodden path once the IMS question is answered correctly.