Does a SIP elevator intercom work during a power outage?

Only if the car terminal, its supplying switch, and the path to the attendance center all ride the emergency/backup source. Confirm from the electrical drawings; a terminal that reboots during generator transfer is a gap exactly when it is needed.

What happens if the network link to the server fails?

Plan a local fallback: register to an on-site server instance or make a direct IP call to the attendance center so the car does not depend on a WAN link. Test the failure on purpose and avoid SIP ALG on the emergency path.

Can the attendance center call into a random elevator car?

Typically no. Emergency intercoms are passenger-initiated: the car places the call and is answered. The station is not a general phone anyone can dial, which keeps the model simple and the cars private.

Why is my elevator call half-duplex or echoey?

Some car hands-free units are half-duplex, so passenger and operator talk over each other; that is a hardware trait to document. Acoustic echo and background noise at the car are handled by the sister products FlyAec and FlyDenoise, not by the SIP server.

How should the attendance center be configured?

As a ring group with a clear overflow chain and a distinct caller-ID range for elevator cars, so the operator sees which car is calling and can prioritize it. Log every emergency call and outcome for audit.

What acceptance tests should I run before sign-off?

Simulate power loss, simulate network loss, place a hands-free call from every car, and confirm the log records car, time, and outcome. The exact criteria and steps follow local regulations and the authority having jurisdiction, not this guide.

ENGINEERING · VERTICAL · 10 min read

Elevator Emergency Intercom: SIP Setup

Moving elevator emergency intercoms to SIP: keep them working through power and network loss, handle one-way calling, and verify against local rules.

2026-11-06 · FlySip engineering · All guides

An elevator emergency intercom is not a convenience; it is the line a trapped passenger pulls to reach help. Converting these stations to SIP simplifies cabling and centralizes the attendance center, but moves a life-safety path onto the building network, so the trade deserves careful setup.

This covers the four conditions that decide whether a SIP elevator intercom works when needed: surviving a power loss, surviving a network loss, the one-way (passenger-initiated) calling model, and the attendance center that answers. It closes with qualitative acceptance checks, because exact requirements vary by location.

Power Loss: Keep the Car Station Alive

The car and machine room usually ride the building's emergency or backup power, and the intercom must stay up on that same source. A SIP terminal in the car draws PoE or a local supply; whichever you choose, it must be on the circuit that survives the outage, not the general office feed that drops first. Confirm from the electrical drawings, not the rack label.

If the terminal is PoE-powered, the supplying switch and uplink must also be on backup power, and the path to the attendance center must remain reachable without mains. A terminal that reboots for ninety seconds during generator transfer is a gap exactly when passengers are most likely to press the button.

Power rule: the car terminal, its supplying switch, and the path to the attendance center must all ride the emergency/backup source - verify from the electrical drawings.

Network Loss: Local Behavior When the WAN Drops

The SIP server may live in a data center or another floor; if that link fails, a car that can only call via the WAN goes silent. For emergency use, decide the local fallback: can the station register to a local server instance, or fall back to a direct IP call to the attendance center, so the call does not depend on a link that just failed?

This is where NAT and media-relay considerations matter. A private address inside the SDP, or a SIP ALG rewriting messages, can break the call. Keep the emergency path's signalling and media as direct as the topology allows, and test the failure on purpose.

Local server instance: register to an on-site node so a WAN drop does not isolate the car.
Direct IP fallback: a configured peer call to the attendance center if registration fails.
Avoid ALG: SIP ALG frequently breaks registration and media; disable it on emergency links.
Test the failure: pull the uplink and confirm the car still reaches help.

One-Way Calling and the Passenger Model

Elevator emergency intercoms are almost always passenger-initiated and one-way to start: the passenger presses the button and the call goes to the attendance center; the center does not generally call into a random car. The config should reflect this - the car may place the emergency call and be answered, but it is not a general phone anyone can dial.

Hands-free operation is typical: the car auto-answers the answering leg so the passenger does not fumble a handset. Set full-duplex where the hardware supports it; if the terminal is half-duplex, document it, because talking over each other is a known failure of cheap hands-free units. (Acoustic echo there is the job of sister products FlyAec and FlyDenoise, not the SIP server.)

Scope: the SIP server connects the call; it does not fix acoustic echo or background noise at the car. Those belong to FlyAec and FlyDenoise. Keep the station's audio expectations realistic.

The Attendance Center That Answers

An emergency intercom is only as good as the desk that answers it. The attendance center is a group of extensions - security, a 24-hour desk, or an external service - configured as a ring group with a clear overflow chain, as in the ring-groups guide. The difference is the stakes: a missed elevator call is not a missed delivery.

Make the emergency call distinct at the center. A dedicated entrance number or caller-ID range for elevator cars lets the operator see 'car 3, building B' instead of an anonymous extension, and routing can prioritize it. Log every emergency call and outcome so the center can be audited like any other access event.

Acceptance Checks (Qualitative)

Before sign-off, exercise the system as an inspector would, even if local rules differ. Simulate a power loss and confirm the car still calls. Simulate a network loss and confirm the local fallback engages. Place a call from every car and confirm it reaches the center and is answered hands-free. Confirm the log records the car, time, and outcome.

The specific criteria, inspection steps, and required indicators are defined by local regulations and the authority having jurisdiction, and vary by region. Match your deployment and test record to those local requirements and the building's own acceptance procedure; this article describes conditions to verify, not a substitute for the applicable code or sign-off.

Power-loss test: car still calls on backup source.
Network-loss test: local fallback reaches the center.
Per-car test: every car places and completes a hands-free call.
Log test: car, time, and outcome are recorded for audit.
Local rules: confirm against the applicable code and acceptance procedure.

Frequently asked questions

Does a SIP elevator intercom work during a power outage?: Only if the car terminal, its supplying switch, and the path to the attendance center all ride the emergency/backup source. Confirm from the electrical drawings; a terminal that reboots during generator transfer is a gap exactly when it is needed.
What happens if the network link to the server fails?: Plan a local fallback: register to an on-site server instance or make a direct IP call to the attendance center so the car does not depend on a WAN link. Test the failure on purpose and avoid SIP ALG on the emergency path.
Can the attendance center call into a random elevator car?: Typically no. Emergency intercoms are passenger-initiated: the car places the call and is answered. The station is not a general phone anyone can dial, which keeps the model simple and the cars private.
Why is my elevator call half-duplex or echoey?: Some car hands-free units are half-duplex, so passenger and operator talk over each other; that is a hardware trait to document. Acoustic echo and background noise at the car are handled by the sister products FlyAec and FlyDenoise, not by the SIP server.
How should the attendance center be configured?: As a ring group with a clear overflow chain and a distinct caller-ID range for elevator cars, so the operator sees which car is calling and can prioritize it. Log every emergency call and outcome for audit.
What acceptance tests should I run before sign-off?: Simulate power loss, simulate network loss, place a hands-free call from every car, and confirm the log records car, time, and outcome. The exact criteria and steps follow local regulations and the authority having jurisdiction, not this guide.

Build the network underneath with the VLAN and QoS guide, and understand failure modes in the NAT traversal and RTP relay guide. See the FlySip product overview for server context.