Read more about how Lift Communications helps serve our community

If your building already staffs a security team, a communications center, or a front desk around the clock, you don't need a third-party monitoring service to answer your elevator emergency calls. You can route those calls to your own staffed desk, on your own network, and keep monitoring entirely in-house. The catch is that your answering point has to meet the same code requirements a commercial monitoring center does: a live response, automatic re-routing if the first responder doesn't pick up within 45 seconds, and a system that stays available during a power event. ASME A17.1-2019 doesn't care who answers the phone. It cares that the call gets answered and assessed.
For a 24/7 staffed building, in-house monitoring is usually the better call. You already employ the people. The call gets answered by someone who knows the building. And the routing can run on hardware that lives inside your own network instead of a vendor's cloud.
When a passenger presses the PHONE button in an elevator car, the call has to reach a person who can talk to them, confirm help is coming, and stay on the line until responders arrive. That person is the answering point. "Monitoring" is just the service of staffing that answering point 24 hours a day, 365 days a year.
Most cloud-hosted elevator phones bundle monitoring into a recurring fee. The vendor's call center is the answering point, and the building pays per car, per month, for as long as the equipment is in service. That model makes sense for an unstaffed building, a small commercial property, or a site with no security presence after hours.
It makes much less sense for a building that already pays people to sit at a desk and watch screens all night.
Four reasons, in the order most building operators rank them.
The people answering already know the building. A passenger trapped in Car 3 of the north tower is talking to someone who knows where the north tower is, which elevator company holds the service contract, and how to reach the on-site engineer. A remote call center reads from a script and then calls the building anyway. In-house monitoring removes the middle step.
No recurring per-car monitoring fee. Third-party monitoring is a subscription. Across a large fleet over a 10 to 15 year equipment life, that adds up. When the answering point is your own already-staffed desk, the monitoring line item goes away. You're paying for hardware once, not for a call center forever.
The call stays inside your network. This is the one that matters most in regulated environments. A cloud-hosted elevator phone routes live emergency traffic through a vendor's external infrastructure. In government, transit, healthcare, defense, and critical-infrastructure buildings, IT security reviews often reject unvetted external systems on principle. Keeping the call on your own network means no new external connection for your security team to vet, and no third party sitting in the middle of a life-safety conversation.
Elevator events land where your operators already look. If your security operations center already watches CCTV, access control, and alarms on one set of screens, an elevator call should show up there too, not on a separate vendor portal nobody's watching at 3 a.m. In-house routing lets the call, the cab, and the surrounding camera feed surface in the same place.
In-house monitoring doesn't lower the bar. ASME A17.1-2019 / CSA B44-19 Section 2.27.1.1.3 sets the requirements for the in-car communication system, and they apply whether your answering point is a vendor call center or your own front desk.
Two-way voice, two-way text, and video. Section 2.27.1.1.3 requires two-way live voice, two-way text messaging for passengers who can't speak or hear, and a video feed so the responder can observe passengers for entrapment assessment. Your in-house answering point needs to be set up to handle all three, including the text exchange.
The 45-second rule. If the initial call isn't answered within 45 seconds, the system has to route automatically to an alternate on-site or off-site responder. For an in-house setup, that means your routing has to fail over from the primary desk to a secondary location on its own. A single phone ringing at one desk with no backup path doesn't meet this.
Four-hour backup power. The communications power source has to support the system for at least 4 hours, and the audible signaling device for at least 1 hour, with automatic transfer to auxiliary power when normal power fails. Your answering equipment and the routing hardware both have to ride through a building power event.
A staffed, authorized responder. The code expects the answering location to be staffed by personnel trained to handle the call. A 24/7 security desk or comms center qualifies. An unattended phone does not. If you're going to monitor in-house, the staffing has to be real and continuous.
Meet those requirements and the code is satisfied. It never specified that a third party had to be the one answering.
Once you've decided to answer calls in-house, the next question is where the call routing actually runs.
Cloud-hosted systems route calls through a vendor's external servers. Even if you wanted your own desk to answer, the call still travels out to the vendor's infrastructure and back. The external dependency stays.
On-premises systems route calls through a PBX inside your own building's network. The call goes from the car to your answering point without leaving your network. No external server, no third-party hosting, and the routing logic is yours to program. For air-gapped or strictly segmented environments, this is often the only model that passes a security review at all.
In-house monitoring and on-premises hosting go together. You can't fully keep a call in-house if the routing depends on an outside cloud.
Here's a question worth asking any elevator phone vendor: what computer is your system running on?
An elevator emergency phone is life-safety equipment. It has to answer on the first press, hold a call for the length of an entrapment, survive a 4-hour power event, and keep working for the 10-to-15-year service life of the elevator. That's an industrial-availability requirement, not a weekend-project requirement.
Some low-cost communication devices are built on hobbyist-class single-board computers. The Raspberry Pi is the best-known example. The Raspberry Pi Foundation is clear about what the board is for: it's an educational and hobbyist computer, designed to make computing cheap and accessible for learning and prototyping. That's a worthy mission. It's also the wrong foundation for life-safety hardware. Consumer single-board computers typically boot from a removable SD card that wears out with continuous writes, lack error-correcting memory, carry no industrial temperature rating, and have no guaranteed long-term firmware or security-update commitment. None of that is a knock on the Raspberry Pi. It's just not what it was built to do.
LiftComm runs on a Linux-based enterprise communications platform built for continuous telephony, not a hobbyist board. The in-car device uses Secure Boot with TLS and SRTP encryption. The on-premises PBX is enterprise-grade IP telephony hardware with built-in redundancy and failover. The point of the Linux platform isn't the operating system for its own sake. It's that the whole stack is purpose-built to stay up, stay secure, and stay supported for the life of the installation.
When you're comparing systems, ask for the platform. The answer tells you whether you're buying communications infrastructure or a prototype.
LiftComm is a fully on-premises elevator emergency communication platform built for buildings that want to keep monitoring in-house. The call goes from the car to your own staffed desk, on your own network, and satisfies ASME A17.1-2019 Section 2.27.1.1.3 along the way.
LC-UCM1400 on-premises PBX. An enterprise IP PBX that lives in your building's data room. It handles all call routing, the 45-second automatic re-route, conferencing to 911 or in-house security, and failover, with no external cloud service in the path. This is the piece that makes in-house monitoring possible: the routing logic is yours, running on your network.
LC-SC1300 Security Desk Phone. A high-end IP video phone for your security desk or lobby answering location. It pulls the call, shows the responder a view of the cab, and supports the voice, text, and video exchange the code requires. It can integrate with Genetec to pull the right CCTV feed automatically when a call comes in from a specific elevator, so the operator sees the call, the cab, and the surrounding area in one view.
LC-EAV Series in-car phone. A touchscreen elevator phone with full-duplex HD audio that satisfies the in-car voice and text-messaging requirements (Section 2.27.1.1.3 (b), (c), and (e)), paired with a camera to satisfy the video-for-entrapment-assessment requirement (f).
Integration with what you already operate. LiftComm plugs into Genetec, access control, CCTV, and SOC platforms already deployed, so elevator calls flow into the same monitoring environment your operators already watch. No separate vendor portal, no separate silo.
LiftComm is currently deployed across the MTA's elevator fleet and is in active use in healthcare, federal, and municipal environments.
Can I monitor my own elevator phones instead of paying a service?
Yes, if your building is staffed 24/7 by people trained to answer the call. ASME A17.1-2019 Section 2.27.1.1.3 requires that the answering location be staffed by authorized personnel and that the system meet the 45-second re-route and 4-hour backup-power requirements. It does not require that a third-party service be the answering point. A 24/7 security desk or communications center can serve as the in-house answering location.
Does in-house monitoring still meet ASME A17.1-2019?
Yes, as long as the in-car system provides two-way voice, two-way text, and video, the call routes automatically to a secondary location if unanswered within 45 seconds, the system carries 4 hours of communications backup power, and the answering desk is continuously staffed by trained personnel. The code sets requirements for the system and the response, not for who owns the answering point.
What's the difference between in-house monitoring and a monitoring contract?
A monitoring contract is a recurring per-car fee paid to a third-party call center that answers your elevator calls. In-house monitoring routes those calls to your own staffed desk instead, removing the recurring fee and keeping the call on your own network. In-house monitoring fits buildings that already staff security or a front desk around the clock.
Why does keeping the call on my own network matter?
Cloud-hosted elevator phones route live emergency traffic through a vendor's external infrastructure. In government, transit, healthcare, defense, and critical-infrastructure buildings, IT security reviews often reject unvetted external systems on principle. An on-premises system keeps the call inside your own network, which means no new external attack surface and no third party in the middle of a life-safety call.
What hardware should an elevator emergency phone run on?
It should run on a platform built for continuous, life-safety availability. Hobbyist single-board computers like the Raspberry Pi are designed for education and prototyping, not for equipment that has to stay up for a 10-to-15-year elevator service life and survive a 4-hour power event. LiftComm runs on a Linux-based enterprise communications platform with Secure Boot, TLS and SRTP encryption, and redundant, failover-capable PBX hardware.
Can the elevator call show up in my existing security operations center?
Yes. LiftComm integrates with Genetec, access control, CCTV, and SOC platforms already deployed, so an elevator call surfaces in the same monitoring environment your operators already watch, alongside the relevant camera feed.
If you run a building with a 24/7 security team, communications center, or staffed front desk and you want to keep elevator monitoring in-house, schedule a 30-minute technical walkthrough with our integration engineers. We'll review your network and security requirements, confirm code applicability with reference to your AHJ, and show how the call routes to your own desk without a third-party service.
Request a technical walkthrough · (212) 732-4658 · info@liftcomm.com
This article is general information about elevator emergency communication codes and is not legal advice or a substitute for review by the project AHJ. Code adoption status and enforcement vary by jurisdiction. Confirm specific requirements for your project before purchasing, specifying, or installing equipment.
Leave us your information and we will get back to you as soon as possible!
