Intercom call routing, media, and door control

Trace call signalling, media and notifications separately. Give door release its own identity check, permissions and recorded result.

Overview#

One user visible call can contain multiple signalling legs, media sessions, transfers, forks, recordings, and an optional access control transaction. Give each its own identity and lifecycle.

Canonical call model#

call request -> routing decision -> destination leg(s) -> answer/timeout/failure
             -> audio/video negotiation -> active media -> hold/transfer/end
             -> optional access request -> PACS decision -> door telemetry

Useful identifiers include source station, native call ID, integration correlation ID, each destination leg, media session, recording object, operator/client, access request, door transaction, and case/incident. Preserve native cause codes and timestamps rather than reducing outcomes to answered/unanswered.

Routing#

Route by approved site, station type, time schedule, occupancy/staffing state, priority, language/accessibility need, and escalation policy. Treat directory and route changes as privileged configuration with version, actor, approval, and rollback.

Test and document:

• simultaneous ringing versus ordered escalation;
• busy, declined, unreachable, unanswered, and controller unavailable states;
• transfer, consult, park/hold, queue, and abandoned call behaviour where supported;
• external PBX/PSTN or mobile/cloud boundary, caller identity, and return path;
• duplicate delivery after failover and recovery;
• priority interaction without allowing routine traffic to starve emergency calls.

Don't infer that push notification delivery means the mobile user received, opened, or answered the call.

Media and recording#

Signalling may describe media while RTP or another transport follows a different route. Record the negotiated codec, endpoints/relay, direction, encryption state, clock/time basis, packet loss/jitter observations, and any transcoding. See SIP and SRTP, RTSP/RTP/RTCP/SDP, and WebRTC.

Recording requires a declared purpose, legal basis/policy, notification or consent where applicable, access control, retention, export, integrity, and deletion. A recording icon in one client doesn't prove every leg was captured or that media remained intelligible.

Measure end to end usability: speech intelligibility, echo, clipping, gain, delay, packet loss, camera framing, lip/event timing, and behaviour during route transitions. Codec support alone isn't evidence of acceptable communication.

Door control boundary#

Preferred flow:

identified operator + active call/context
 -> constrained unlock request with door and reason
 -> PACS policy/controller decision
 -> decision result
 -> lock-output/contact/door-state telemetry
 -> attributable audit across both systems

• The intercom must not possess broad controller credentials merely to request one action.
• Scope operator rights by site, door, time, call state, and action; require stronger confirmation where risk warrants.
• Avoid exposing raw relay toggles in general clients. Use a semantic, bounded request.
• Don't substitute video or voice recognition for approved credentialing without explicit policy and assessment.
• A successful API or relay write isn't proof the lock changed or door opened/closed.
• Life safety, egress, emergency release, lockdown, and fire interaction remain with the approved design and authority.

See Locks, egress, and life safety.

Failure safe presentation#

Show stale video, missing audio, failed route, unavailable recording, PACS timeout, access denial, unknown door state, and audit delivery failure explicitly. Never replay a cached image as live without prominent timestamp and state. If an operator can't verify the caller or door, the UI should support the approved alternate process rather than silently weakening authorisation.

Source baseline#

IEC 62820-1-2:2026 addresses IP building intercom systems; IEC 62820-2:2017 covers advanced security intercom used for danger/emergency recognition and instruction. Exact protocol, conditional functions, access integration, and conformity remain product specific.

Return to Intercom and emergency communication systems.