Building intercom systems let a visitor communicate with an occupant or operator before an entry decision is made. The complete service connects calling, answering, audio or video and an authorized release request, with dependencies that vary by architecture. IEC 62820 addresses building intercom systems; its general and IP-system parts both have 2026 editions.[1][2]
The most useful design distinction is between the conversation and the door action. Trace each path separately, then define how they work together. A successful conversation does not, by itself, demonstrate a completed or authorized door transaction.
What building intercom systems do
An entry intercom provides communication at a building entrance. The IEC series establishes that system context, while IEC 62820-3-1:2017 covers application guidance across requirements definition, planning and the lifecycle.[1][3] A project specification should therefore begin with the visitor journey and the people responsible for answering.
For an illustrative apartment entrance, the journey might include finding a destination, placing a call, reaching the intended resident, holding a usable conversation and requesting entry. A staffed office could use a different answering role. Neither example determines the transport technology or authorizes every answering person to release every entrance.
Describe the service during ordinary hours and when the intended recipient is unavailable. Who owns the directory? Who answers a call that cannot reach its selected destination? What should the visitor understand when no authorized responder is available? These are proposed requirements questions that follow from defining the complete communication task.[3]
Keep ordinary visitor-entry communication separate from emergency or refuge communication requirements. A project’s emergency communication design needs its own governing scope and acceptance process. Do not treat a camera, speaker or mobile answering application as evidence that another communication duty has been fulfilled.
From visitor call to entry request
Separate the transaction into caller selection, signaling, media exchange and the entry-control interface. SIP, where used, establishes, modifies and terminates sessions; it is one part of a multimedia architecture rather than the complete entry service.[4]
Media negotiation is another function. RFC 3264’s offer/answer model describes accepted streams and compatible formats. A call can therefore have signaling requirements and separate audio/video compatibility requirements.[5] The project needs evidence for the intended combination of endpoints and functions.
The AXIS I8116-E documentation provides a bounded example of a release path: a received DTMF command can be associated with a relay action or a request to a door controller. Its contact configuration also addresses availability and fallback destinations.[6] These are documented product functions, not guarantees about every intercom or telephone integration.
Use a transaction schedule to capture the intended service.
| Stage | Project question |
|---|---|
| Destination selection | How does the visitor find and select an authorized destination? |
| Call routing | Which configured path reaches the intended answering role? |
| Answering | What confirms that the recipient has accepted the call? |
| Conversation | Which audio and video functions must work together? |
| Entry request | Who may request release, and what interface carries the request? |
| Unanswered call | What supported fallback or visitor instruction applies? |
| Completion | What feedback and records does the owner need? |
This is a proposed requirements schedule. The selected design must establish the actual states and feedback at each stage. Keeping them explicit prevents a demonstration of ringing from being mistaken for acceptance of the entire visitor-entry service.
Stations and receiving endpoints
Describe stations by their operating role before listing their features. The entry station serves the arriving visitor; the receiving endpoint serves the answering person. Requirements definition should explain what each person needs to accomplish and which functions support that task.[3]
Conversation modes deserve attention. Aiphone’s JO-1FD specification describes a video receiving station with hands-free and push-to-talk operation. It also documents its dedicated wiring arrangement. These product facts show that conversation mode, video capability and interface architecture are separate descriptions.[7]
For an illustrative staffed reception point, ask the user to demonstrate how a call is noticed, answered and transferred or concluded using the proposed arrangement. For an illustrative resident endpoint, ask how the user recognizes the entrance being called and performs only the actions within that user’s authority. These proposed demonstrations test the journey rather than a collection of icons.
Directory administration needs a similarly clear task description. Assign responsibility for the displayed destination, the routed destination and updates when occupants change. In the Axis example, availability and fallback contacts are configured functions.[6] Specify the required behavior for the selected system and test both the normal destination and its authorized fallback.
Avoid assuming that every endpoint offers the same capability. Write an endpoint schedule that states required calling, answering, viewing and release functions. The schedule should identify what the project needs demonstrated on each supported endpoint type, including any receiving application involved in the accepted design.
Audio, video and transport choices
Audio-only and video describe communication capabilities. IP and dedicated wiring describe aspects of transport and architecture. Aiphone’s JO-1FD example carries video on a dedicated station wiring arrangement, while its IPW-1VC product supports specified IP connections over existing conductors. Conductor count alone therefore does not identify the communication architecture.[7][8]
Cable reuse is a product-specific compatibility question. A converter’s documented support applies to its stated equipment and conditions; it does not establish arbitrary interoperability between old stations and new IP devices.[8] Require the proposed design to identify the supported endpoints, conversion equipment and accepted cable conditions.
For SIP-based systems, inspect the complete protocol relationship. RFC 3261 provides session signaling; RFC 3264 addresses media offer/answer; RFC 3550 provides RTP and its control protocol for real-time media. RTP does not reserve network resources or guarantee delivery or quality of service.[4][5][9]
Release signaling needs its own compatibility check. RFC 4733 defines RTP payloads for telephone events including DTMF, with supported events negotiated. A generic SIP claim does not establish support for the release event or behavior the project needs.[10]
An illustrative acceptance description might require the intended endpoints to establish a call, exchange intelligible audio, deliver the required image and perform the authorized release-request function. Record the actual software versions and configuration used for the test. This proposed test addresses the service across protocols and applications without prescribing device-specific commands.
Local and remote call architectures
Identify where routing and receiving functions operate. In the AXIS I8116-E documentation, direct peer-to-peer SIP calling and PBX-based calling are different supported arrangements, and the PBX can be locally or remotely hosted.[6] This demonstrates that an IP call can be local; “IP” does not inherently mean “public-internet-dependent.”
Draw the selected call path using actual functions: entry station, routing service if present, receiving endpoint and any required remote service. Then draw media flow, release-request flow and management access separately. The separation follows the distinct signaling, media and application functions described by the RFCs and product documentation.[4][5][6]
For a proposed mobile or hosted arrangement, ask which functions depend on the remote service and which functions remain within the building. Ask the provider to demonstrate the accepted answering and fallback behavior. Do not infer it from the presence of an application, a cloud icon or a local network connection.
An illustrative office may want local reception answering during a wide-area interruption. Write that as a functional requirement and obtain a supported architecture that meets it. A different project may accept a different limitation. The important document is the accepted dependency and limitation, with a responsible owner, rather than a universal promise about local or hosted systems.
Include administration in the path drawing. A service may have one dependency for ordinary calling and another for directory changes or remote maintenance. The project team should confirm those actual dependencies so the operating procedure describes what can be changed, by whom, in each agreed operating condition.
Access-control and door interfaces
An intercom’s entry request needs a clearly defined receiving function. The Axis documentation distinguishes its relay and controller-related release arrangements and separately documents power and connection options.[6] Specify the boundary between the communication service, authorization decision and physical opening.
For an illustrative reception workflow, define which entrance the responder is viewing or discussing, whether that responder has release authority and what evidence confirms the resulting action. The proposed workflow must be implemented through supported equipment and the governing door design. It does not establish lock wiring, emergency release or power-loss behavior.
Coordinate video surveillance integration when the owner needs separate assessment or recording functions. A video intercom’s call image and a surveillance stream are distinct capabilities in 2N’s camera documentation.[11] Verify the required destinations and functions rather than assuming that a visible call image is automatically available to every recording or management system.
Keep interface questions specific. What identifies the entrance? What carries the authorized request? Which component acts on it? What feedback exists? What happens if the receiving function is unavailable? These are proposed design questions based on tracing the call and command independently.[3][6]
The entrance’s inside-exit and emergency arrangements remain part of its applicable door and life-safety design. Assign those decisions to the responsible project roles and coordinate the intercom interface with the approved arrangement. A communication feature should not become an undocumented substitute for the opening’s governing behavior.
Power, networks and service continuity
Assess station power and lock power separately. The Axis manual distinguishes PoE, external supplies and potential-free relay connections in its supported arrangements.[6] Knowing how the station is powered does not establish how every connected lock is supplied or how the opening behaves when a supply is unavailable.
Use a dependency schedule to turn continuity objectives into questions for the selected architecture.
| Function or condition | Evidence to request |
|---|---|
| Entry station unavailable | Effect on calling and the visitor’s understood fallback |
| Receiving endpoint unavailable | Supported alternate destination or accepted limitation |
| Routing service unavailable | Which accepted local or remote paths remain usable |
| Building network interrupted | Affected signaling, media and management functions |
| Wide-area service unavailable | Difference from a local-network interruption |
| Release interface unavailable | Indication and operating ownership of the limitation |
| Service restored | Evidence that calling, media and authorized entry requests work again |
The table is a proposed assessment tool, not a prediction that every arrangement provides redundancy. Actual behavior comes from the supported design and its commissioning evidence. Map call, media, release and management dependencies independently so an available function does not conceal another unavailable one.[4][5][6]
For an illustrative handover test, ask the team to explain an agreed service interruption without touching configuration. The responder should be able to identify the affected visitor task, the available authorized alternative and the person responsible for restoration. Then compare that explanation with the documented test result. This checks that the operating procedure reflects the accepted architecture.
Usability, privacy and system security
A usable conversation depends on conditions at the entrance and receiving point. 2N’s audio documentation discusses ambient noise, microphone gain and feedback-related settings; its camera documentation includes exposure and lighting-related controls.[12][11] These are equipment-specific capabilities, not universal promises of intelligibility or image quality.
Specify the task under representative conditions. Ask the project team to demonstrate a conversation at the intended entrance and a view that supports the intended assessment. Record the operating conditions and accepted limitations. Raising a volume setting or selecting a higher image specification is not an acceptance method by itself; the proposed test should follow the actual visitor and responder tasks.[3][11][12]
Accessibility and the complete interaction
In the US ADA framework, section 230.1 scopes two-way communication at entry points to section 708. Section 708.2 requires audible and visual signals for the scoped systems, and section 708.4 includes additional provisions for residential dwelling units.[13][14] Apply the actual scoping and technical requirements to the project rather than assuming that video alone establishes accessibility.
Record who evaluates the visitor controls, signals and receiving interface against the applicable requirements. A useful project question is whether the user can understand the communication state and complete the intended task with the provided interfaces. This general planning question does not replace a jurisdiction-specific accessibility assessment or establish mounting dimensions.
Privacy and recording
Separate live conversation, live viewing and retained recording in the requirements. UK ICO guidance connects surveillance processing to a defined purpose, proportionate collection, authorized access and purpose-based retention. It does not provide one universal retention duration for every system.[15]
Continuous audio recording requires its own necessity and transparency consideration; the need to speak with a visitor does not by itself justify recording all surrounding conversations.[16] Define what is collected, why it is needed, who can access it and when it is removed. The organization responsible for processing must establish the applicable legal basis and local obligations.
Cybersecurity ownership
NISTIR 8259A identifies an IoT device capability baseline covering identification, configuration, data protection, logical access to interfaces, software updates and cybersecurity-state awareness. It is a starting point to tailor to system needs, not a complete intercom certification.[17]
Assign ownership for device inventory, authorized administration, supported updates and security-state information. Ask which interfaces are required for the accepted service and how unnecessary access is restricted. Include the directory and release-request functions when defining authorized configuration, because the project’s security task extends beyond establishing a call.[17]
For SIP systems, separate signaling protection from media protection. RFC 8862 explains the relationship between SIP, SDP and protected RTP media; TLS for signaling alone does not establish that the audio or video stream is protected.[18] Require the selected implementation to document the intended protections and supported identity and key arrangements without inferring them from a single protocol label.
Requirements before detailed design
Begin with the complete visitor journey and the responsible answering roles. Then record destination management, endpoint functions, call routing, required media and the authorized entry-request interface. IEC’s application-guideline scope provides a lifecycle basis for requirements definition; the protocol and product sources explain why these functions need separate verification.[3][4][5][6]
A proposed requirements package should include an entrance schedule, an endpoint schedule and a dependency schedule using consistent identifiers. Add representative usability conditions, accessibility responsibilities, data-processing decisions and cybersecurity ownership. State accepted limitations explicitly so the operations team can explain what the system is expected to do.
Acceptance should follow the visitor transaction. Demonstrate destination selection, the correct answering path, intelligible conversation, the required useful view, the authorized release-request behavior and the agreed unanswered-call route. Repeat the relevant checks for the documented outage and recovery conditions. This is a proposed functional method, with safe procedures and expected results to be supplied by the project.[3][5][6][11][12]
Finally, have the owner, integrator and operating team describe the same entrance from their own responsibilities. Resolve differences before detailed station design and installation proceed. A coordinated specification should let each team trace what the visitor does, what the responder may do, which technical functions carry the transaction and what evidence confirms the accepted result.
For an illustrative final handover conversation, ask the answering person to explain what happens when the first destination cannot answer. Compare that explanation with the configured fallback and the commissioning record. Resolve any disagreement in the operating documentation. This proposed check keeps the accepted service understandable to the people who will use it after the design team leaves.[3][6]
References
- IEC. IEC 62820-1-1:2026 — General system requirements. 30 March 2026, Ed.2.0; Abstract/product detail. webstore.iec.ch (accessed 22 October 2026).
- IEC. IEC 62820-1-2:2026 — IP building intercom systems. 27 July 2026, Edition 2.0; Abstract and Product detail (Publication date; Edition). webstore.iec.ch (accessed 22 October 2026).
- IEC. IEC 62820-3-1:2017 — General application guidelines. 13 December 2017, Ed.1.0; Abstract. webstore.iec.ch (accessed 22 October 2026).
- IETF / RFC Editor. RFC 3261 — SIP: Session Initiation Protocol. June 2002; updates listed on page; Sections 2,4. www.rfc-editor.org (accessed 22 October 2026).
- IETF / RFC Editor. RFC 3264 — An Offer/Answer Model with SDP. June 2002; updates listed on page; Sections 1,4,6. www.rfc-editor.org (accessed 22 October 2026).
- Axis Communications. AXIS I8116-E Network Video Intercom — technical documentation. Live manual; revision date not established; Contacts; direct/PBX SIP; DTMF release; VoIP; connectors. help.axis.com (accessed 22 October 2026).
- Aiphone. JO Series — JO-1FD Specification. October 2022; pp.1–2. www.aiphone.com (accessed 22 October 2026).
- Aiphone. IPW-1VC — converter set. Undated live page; Description and features. www.aiphone.com (accessed 22 October 2026).
- IETF / RFC Editor. RFC 3550 — RTP: A Transport Protocol for Real-Time Applications. July 2003, STD 64; Abstract; Section 1. www.rfc-editor.org (accessed 22 October 2026).
- IETF / RFC Editor. RFC 4733 — RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. December 2006; Abstract, p.1, and section 2.5.2.1 (supported event indication). www.rfc-editor.org (accessed 22 October 2026).
- 2N. 2N IP Intercom configuration manual section 5.5.3 Camera. Live manual; version selector not resolved; Internal camera; exposure; day/night; privacy masking. wiki.2n.com (accessed 22 October 2026).
- 2N. 2N IP Intercom configuration manual section 5.5.2 Audio. Live manual; version selector not resolved; Master volume; input gain; feedback filter. wiki.2n.com (accessed 22 October 2026).
- US Access Board. ADA Accessibility Standards — Chapter 2. 2010 ADA Standards, live presentation; Section 230.1. www.access-board.gov (accessed 22 October 2026).
- US Access Board. ADA Accessibility Standards — Chapter 7. 2010 ADA Standards, live presentation; Sections 708.1–708.4. www.access-board.gov (accessed 22 October 2026).
- UK Information Commissioner’s Office. Data protection principles when using surveillance systems. Live guidance; access date governs snapshot; At a glance; minimisation; retention; secure storage. ico.org.uk (accessed 22 October 2026).
- UK ICO. CCTV for your organisation: things you need to do. Live guidance; Steps 2,4,5. ico.org.uk (accessed 22 October 2026).
- NIST. NIST IR 8259A — IoT Device Cybersecurity Capability Core Baseline. May 2020; Section 2, Table 1; printed pp.3,5–10; Appendix A. nvlpubs.nist.gov (accessed 22 October 2026).
- IETF / RFC Editor. RFC 8862 — Best Practices for Securing RTP Media Signaled with SIP. January 2021; Sections 1,3. www.rfc-editor.org (accessed 22 October 2026).
