Lift Phone Gateway Vendor Evaluation Guide: 12 Questions for OEMs and Integrators
The Robustel EV8100 Elevator Voice Gateway provides a useful reference architecture for evaluating a lift phone gateway because it brings analogue FXS, IP and mobile voice options, dual SIM, industrial interfaces, local battery provision and remote device management into one platform. Those capabilities are only the starting point. A portfolio buyer still has to establish whether the handset, carrier service, monitoring centre, power system and maintenance process work together as one emergency-call service.
For Australian portfolios, terms such as AS 1735, RCM, lift emergency phone and two-way communication should lead to specific evidence. A vendor presentation may prove that a gateway can register on a network; it does not prove that an older autodialler will exchange DTMF correctly, that a call will reach the right monitoring-centre record during mains failure, or that another engineer can recover the service two years later. The following twelve questions are designed to expose those gaps before the rollout contract is signed.
Evaluate the Installed Voice System Before Comparing Gateways
1. Which Existing Lift Phones and Line Conditions Have Been Tested?
Ask for a compatibility record covering the actual handset and autodialler population, not a statement that the gateway has an FXS port. Useful evidence includes loop voltage and current, supported DTMF behaviour, caller-ID handling, maximum tested loop resistance, call clearing and any known incompatibilities. An older autodialler can seize the line and produce a dial sequence while still failing identification or acknowledgement at the monitoring centre.
The portfolio sample matters. Test the common modern unit, the oldest type still in service and any model with unusual line-conditioning equipment. Robustel’s EV8100 PSTN replacement application example illustrates the migration boundary around an existing analogue handset, the FXS interface and IP or mobile voice paths. It is an architecture example, so the buyer must still prove each installed phone type.
2. What Is the Primary Voice Path, and What Takes Over When It Fails?
Require the proposal to identify the normal call path in operational terms: handset to FXS, gateway voice method, carrier or SIP service, and monitoring-centre termination. If SIP or VoIP is primary and VoLTE is secondary, ask which condition initiates the change, how registration is re-established and what happens to a call already in progress. If VoLTE is primary, confirm that the selected SIM profile, network and device variant have been accepted together.
This question often exposes unclear ownership. The gateway supplier may own hardware behaviour, the mobile provider owns service activation, and the monitoring centre owns call routing and site identity. The integrator needs one test plan that crosses all three boundaries; otherwise each party can report its own component as healthy while the passenger still has no completed call.
3. Which Australian Mobile Networks, SIM Profiles and Regional Variants Are Accepted?
Obtain the exact regional order code, supported LTE bands, firmware baseline, SIM requirements and carrier or service-provider acceptance evidence for the planned voice method. A successful LTE data session is not a VoLTE acceptance test. Voice registration, outgoing call routing, presentation of the expected calling identity and the monitoring centre’s return-call process all need to be checked on the intended service.
For a national estate, record where the network choice changes by region or building. A single carrier may be commercially convenient but weak in particular lift machine rooms or basements. Dual-SIM hardware can add subscription diversity, yet it cannot correct poor antenna placement or two services that ultimately share the same local radio failure.
Test Resilience as an End-to-End Call Service
4. What Does Dual SIM Actually Do in This Design?
Ask for the operating state of each SIM, the conditions that trigger a change, expected registration behaviour after the change and the return policy when the preferred service recovers. The useful engineering answer describes a state machine, not merely “automatic failover”. It should also explain how technicians distinguish a planned switch from a radio, account or configuration fault.
Two SIMs share the gateway, power system and usually the same antenna environment. They can reduce dependence on one subscription or operator, but they are not two independent emergency-call systems. The acceptance test should therefore isolate an operator or profile failure without pretending that the exercise also proves power, antenna or gateway redundancy.
5. What Happens During Mains Failure and Battery Degradation?
Request the approved battery arrangement, charging behaviour, operating and charging temperature limits, runtime test method, replacement interval and responsibility for supplying the cells. Measure the emergency-call path under battery power, not just the gateway’s ability to remain switched on. A unit can stay online while the analogue handset, external equipment or antenna amplifier has lost its own supply.
Battery evidence must survive beyond commissioning. The maintenance plan should say how capacity is retested, how an ageing cell is identified and which alarm reaches the responsible team. Runtime depends on cell type and condition, temperature, call activity and attached loads; a theoretical battery calculation is useful for planning but does not replace a witnessed site test.
6. Which Approvals Apply to the Exact Ordered Variant and Complete Installation?
Ask for current RCM evidence and the project documents relevant to the exact regional order code. Component evidence and lift-system obligations address different parts of the solution. The integrator remains responsible for showing how the gateway, existing phone, power arrangement, network service and monitoring-centre workflow meet the project’s requirements.
Robustel’s TSARO case study is exact-model deployment evidence for an integrator-led replacement of analogue line service using EV8100. It demonstrates the value of treating compliance, voice migration and field rollout as one programme. It does not establish automatic acceptance for another carrier, lift portfolio or jurisdiction.
Use an evidence register so that a polished vendor answer cannot carry more weight than the material behind it:
| Evidence supplied | What it can support | What it cannot prove alone | Procurement treatment |
|---|---|---|---|
| Current product or regional document | Ordered capability or approval scope | Site interoperability or completed emergency call | Necessary baseline |
| Bench result with named phone and service | Compatibility under recorded conditions | RF performance or battery runtime at every building | Repeat on representative sites |
| Witnessed end-to-end site test | Operation of that installed call path | Fleet-wide consistency or future configuration control | Acceptance evidence for the site |
| Written operating commitment | Ownership, response and support obligation | Technical performance without a test | Include in service governance |
| Unverified verbal statement | A question worth investigating | Approval, compatibility or operational readiness | Do not use as a rollout gate |
Make Acceptance and Ongoing Service Visible to Operations
7. How Is a Call Proven From the Lift Car to the Responsible Operator?
The witnessed test should start from the passenger interface and finish with the monitoring centre following the correct response record. Include alarm initiation, calling identity, DTMF exchange where used, two-way speech, call clearing and return call where required. Repeat the path during the defined degraded conditions, including mains failure and the loss of the preferred voice service.
A registered modem, dial tone or successful call to a technician’s mobile proves only part of the chain. Procurement should require an acceptance record with time, site, handset type, gateway configuration, service path and monitoring-centre confirmation. That record becomes the baseline for later fault diagnosis.
8. Which Conditions Can Be Monitored Remotely, and Which Still Need a Service Test?
Separate gateway telemetry from proof of the passenger service. Online status, signal condition, data use, configuration, firmware and alarms can help a maintenance team find sites that need attention. They do not automatically prove battery capacity, handset audio, correct DTMF exchange or monitoring-centre handling.
The useful proposal maps each observable condition to an owner and response time. A low-signal trend may lead to an antenna survey; loss of gateway contact may require a site visit; a missed scheduled call may require both telecom and monitoring-centre investigation. Without that response map, additional telemetry creates a longer alarm list rather than better service assurance.
9. How Are Security, Remote Access and Configuration Changes Governed?
Ask which VPN and access mechanisms are supported, how accounts and roles are assigned, whether changes are auditable, how credentials are rotated and how firmware or configuration updates are approved. Remote support should not expose the lift controller or building LAN merely because the voice gateway shares the service room.
The operating model should also define the recovery path after a failed change. Keep an approved configuration, record the installed firmware and preserve a way to reach the site when the preferred WAN or management path is unavailable. Security is part of availability when an access-control mistake can delay fault recovery.
Plan Integration, Lifecycle and Handover Before Scaling
10. Can the Platform Integrate With Lift Data Without Crossing the Control Boundary?
Industrial interfaces can support useful monitoring options, but ports are not application compatibility. Request the exact controller protocol, signal direction, electrical interface and data ownership for every proposed integration. A digital input used to observe a dry contact is a different engineering commitment from serial communication with a controller, and neither should be allowed to alter safety-related lift logic without the appropriate system design and approval.
The buyer should also decide whether the voice gateway is the right aggregation point. A small, clearly owned status set may fit. A broad lift analytics programme could justify a separate integration layer so that emergency voice remains simple and changes to telemetry do not disturb the call service.
11. What Is the Lifecycle, Support and Escalation Model?
Record who owns the hardware configuration, SIM contract, SIP account, monitoring-centre record, firmware approval, batteries, periodic testing, spares and replacement stock. At portfolio scale, those responsibilities often sit in different organisations. A fault that moves between them without a named escalation owner can remain open even when every supplier responds within its own scope.
Ask how a replacement unit receives the approved configuration and identity, how quickly a failed gateway can be exchanged, and which changes require the monitoring centre to update its records. Lifecycle evidence is not administrative overhead; it determines whether an emergency-call service can be restored predictably after the original project team has moved on.
12. What Evidence Will Be Delivered at Handover and Retained for Audit?
The minimum handover should include order code, firmware, SIM and service details, antenna and power installation, battery specification, handset compatibility result, witnessed monitoring-centre test, remote-management registration and as-installed diagrams. Each item needs a date and owner. A generic commissioning certificate is difficult to use when the next engineer must isolate a particular call-path failure.
For a multi-site rollout, standardise the record format before the pilot. That makes missing fields visible and allows operations teams to compare buildings without translating twenty integrator templates. It also creates a controlled baseline for later firmware, carrier or monitoring-centre changes.
How the Robustel EV8100 Elevator Voice Gateway Supports a Verifiable Lift-Phone Service
The Robustel EV8100 Elevator Voice Gateway documents one FXS port, SIP over UDP, SIPs and SRTP, VoIP with VoLTE as a backup voice line, two physical SIM slots, two Ethernet ports, RS-232, RS-485, CAN, four digital inputs and one dry-contact relay. RobustOS Pro and RCMS provide the device platform and management layer, while optional Wi-Fi and Bluetooth depend on the ordered variant.
Those capabilities align well with a migration project that must preserve an existing analogue handset, add managed IP or mobile connectivity and expose selected device or lift signals. The architecture can reduce the number of separate boxes an integrator has to support, but it also concentrates responsibilities. Voice configuration, SIM service, antenna placement, battery provision and any controller integration still require named owners and site acceptance.
| Evaluation area | Verified EV8100 contribution | Project evidence still required |
|---|---|---|
| Existing analogue phone | One FXS interface | Named handset/autodialler test and line-condition limits |
| Voice architecture | SIP/VoIP and documented VoLTE backup voice path | Selected service profile, routing and monitoring-centre acceptance |
| Subscription diversity | Two physical SIM slots | Switching policy, re-registration time and shared-failure assessment |
| Local power continuity | Holder for specified 18650 flat-top cells | Cells, runtime target, temperature conditions and maintenance method |
| Remote operations | RCMS-supported device management | User roles, alarm ownership, change approval and escalation workflow |
| Regional deployment | ANZ variant information with RCM in current product material | Exact order code and current project-specific compliance evidence |
The fit is weaker when a project needs only a simple IP handoff to a fully digital lift communication system, or when extensive lift-data integration would turn the voice gateway into an uncontrolled application hub. In those cases, keep the emergency voice path small and place wider analytics in a separately governed architecture.
Convert the Twelve Answers Into a Controlled Pilot
Score each answer by evidence quality and operational consequence. A missing battery-maintenance owner is more serious than a missing convenience feature; an untested handset population is a rollout blocker; an unclear return-to-primary policy may be acceptable only if the support team has a recovery procedure. Weighting the questions prevents a proposal with many minor strengths from hiding one weak emergency-call dependency.
The pilot should include a representative older autodialler, a building with difficult indoor RF, mains-failure operation, the actual monitoring centre and the people who will maintain the service. The Robustel’s EV8100 Quick Pitch video is useful for aligning stakeholders on the product role before the pilot. Approval should follow the witnessed evidence pack, not the overview.
Häufig gestellte Fragen
Q1. What is a lift phone?
It is the emergency communication equipment used by trapped passengers or service personnel to contact a responsible monitoring or response service. The complete service also depends on its transmission path, power arrangement and operating procedures.
Q2. How do elevator phones work?
An alarm action starts a call from the lift communication device through an analogue, cellular or IP path to a monitoring point. A useful acceptance test follows that call through identification, two-way speech, operator response and call clearing.
Q3. What are the regulations for lift telephone lines?
Requirements depend on the jurisdiction, building and lift standard. Australian projects should obtain current advice on AS 1735 and telecommunications obligations, then verify the complete installed system instead of relying on one component label.
Q4. Who monitors elevator phones?
They are commonly answered by a lift service provider, dedicated monitoring centre, building service or another responsible organisation named in the site’s arrangement. The handover should identify the answering party, escalation route and response ownership.
Q5. What should buyers verify about the Robustel EV8100 Elevator Voice Gateway?
Verify the exact regional variant, carrier and SIM profile, FXS compatibility, SIP or VoLTE call path, battery design, monitoring-centre workflow and remote-management handover. The EV8100 is strongest when those items are accepted as one service rather than separate supplier checks.
Schlussfolgerung
The Robustel EV8100 Elevator Voice Gateway is a strong fit for lift portfolios that need to retain a compatible analogue phone while moving the transmission and management layers onto a controlled IP or mobile architecture. Its value is clearest when the project uses the FXS, voice, SIM, power and management capabilities as parts of one testable service—not as independent brochure features.
The twelve questions turn procurement into an ownership and evidence exercise. A buyer should leave the pilot knowing which handset population has been proved, which voice path is primary, how degraded operation behaves, who receives each alarm, and what another engineer will find in the handover record. If any of those answers remain verbal or split across suppliers, the rollout is not yet ready to scale.
For final approval, select representative buildings and witness the passenger-to-monitoring-centre call under normal service, the agreed network-failure condition and mains failure. That evidence gives the OEM, integrator and building operator a common basis for accepting the design and supporting it after handover.
Explore More Articles About Robustel Lift Connectivity
Über den Autor
Robert Liao | Technical Support Engineer
Robert is an IoT Technical Support Engineer at Robustel, specializing in industrial networking and edge connectivity. A certified Networking Engineer, Robert focuses on the deployment and troubleshooting of large-scale IIoT infrastructures. His work centers on architecting reliable, scalable system performance for complex industrial applications, bridging the gap between field hardware and cloud-side data management.