Imagine this: a visitor presses the intercom button, and your phone instantly rings, showing the camera video. With one tap, you open the door. Behind this simplicity lies a complex engineering puzzle: WebRTC or SIP stack, ONVIF protocol, push notifications with sub-second latency even when the app is closed, lock relay control via the device API, and event recording. We develop mobile apps for intercoms on a turnkey basis, from architecture selection to publishing on the App Store and Google Play. A typical project takes 4 to 12 weeks and costs between $15,000 and $50,000, depending on hardware compatibility and multi-apartment requirements.
Consider a typical scenario: in an apartment building, a single app for residents routes a call from the intercom of a specific entrance to the correct apartment. It must also support video recording, guest QR codes, and integration with the existing access control system. Our team has 10+ years of experience in embedded and mobile solutions, so we guarantee tight deadlines and transparent reporting.
Why Protocol Choice Matters
The first question in design is the type of intercom hardware. It determines which video communication protocol to use.
Ready-made IP Intercoms with SIP — Mobile App Development
Devices like Hikvision DS-KV6113, Grandstream GDS3710, Beward DS06M support SIP and ONVIF. The phone registers as a SIP client on Asterisk/FreeSWITCH. Incoming call from intercom → SIP INVITE → server → push to phone → CallKit (iOS) / ConnectionService (Android).
Custom Intercom on a Single-Board Computer
We use Raspberry Pi, ESP32-S3, or NXP i.MX — we choose the stack ourselves. WebRTC via Pion (Go) or aiortc (Python) on the device, signaling via WebSocket to our server, then the mobile client.
Cloud Intercom
Proprietary solutions (Ring, Dahua, Hikvision EZVIZ) provide P2P SDKs. Integration is fast but leads to vendor lock-in.
How to Ensure Call Delivery in Fractions of a Second
Notification delay is critical: a guest is at the door. On iOS, the right path is APNs VoIP push with PKPushRegistry and PKPushType.voIP. The system wakes the app immediately, even from Force Quit, and shows the native call interface via CXProvider. According to CallKit documentation, this is the standard approach for VoIP apps.
let update = CXCallUpdate() update.remoteHandle = CXHandle(type: .generic, value: "Door entrance") update.hasVideo = true update.localizedCallerName = "Intercom" provider.reportNewIncomingCall(with: callUUID, update: update) { error in ... } The APNs VoIP certificate is separate from the push certificate. Don't forget voip in UIBackgroundModes in Info.plist.
On Android, we use ConnectionService + FCM with high priority (priority: high). TelecomManager.addNewIncomingCall() shows the system call. Problem: on Xiaomi, Huawei, OPPO aggressive battery optimizations kill the FCM connection. Solution: JobScheduler keepalive + instruct the user to add the app to exceptions. For Huawei, we use HMS Push.
For cross-platform projects (Flutter), we use flutter_callkit_incoming and firebase_messaging — native bindings to CallKit and ConnectionService.
WebRTC Video Communication
After answering the call, a WebRTC peer connection is established. Signaling: SDP exchange via our WebSocket server (or Asterisk with WebSocket transport for SIP/WebRTC). ICE candidates are gathered via STUN; for NAT traversal, we use TURN (Coturn). Video from the intercom camera is rendered in RTCMTLVideoView (Metal, iOS) or SurfaceViewRenderer (Android). Audio — RTCAudioTrack. AEC (echo cancellation) is built into WebRTC — critical to prevent echo through the intercom speaker. Video latency: 150-400 ms on Wi-Fi, 400-800 ms on 4G — acceptable for deciding to open or not.
Protocol comparison: SIP stack is suitable for standard IP intercoms, but WebRTC provides 3-5 times lower video latency due to direct P2P connection.
Lock Control
HTTP or MQTT request to the device or server: POST /api/unlock or publish("home/door/unlock", "1"). Confirmation of opening via door sensor (optional): the OPEN event is displayed in the app. The "Open" button is active only during the call — after ending, it disappears. Event log: each call, opening, and rejection is written to the database with timestamp and userId.
Video Event Recording
Video recording for each call (ringback recording): a media server (Janus record plugin, Ant Media) writes the stream to WebM/MP4. Storage in S3/MinIO with retention of the last 30 events or 7 days (lifecycle rule). The mobile client shows history: a timeline with preview of the first frame, duration, and a play button using AVPlayer / ExoPlayer from S3 presigned URL.
Multi-Apartment Building
Multiple entrances, multiple apartments. Routing: the intercom at entrance 3 calls only residents of apartments in entrance 3. In Asterisk: dialplan with Dial(SIP/apartment_${EXTEN}). Each apartment is a separate SIP account. In the app, the user is linked to their apartment account. Guest access: the owner issues a temporary QR code with a limited validity period.
How routing works in a multi-apartment building
Each entrance intercom has a unique SIP number. When the call button is pressed, the intercom sends an INVITE with the apartment number (DTMF). Asterisk converts the DTMF to the apartment's SIP account number. If the call is not answered, it is forwarded to the mobile app via VoIP push. On failure, video is recorded and a notification is sent.Step-by-Step Intercom Integration Process
- Hardware audit — analysis of intercom protocols, ONVIF/SIP support, relay output capabilities.
- Architecture design — stack selection (SIP vs WebRTC), server side, DBMS.
- Server-side development — Asterisk/WebRTC server, REST API for the app, MQTT broker.
- Mobile client development — iOS (Swift + CallKit) and Android (Kotlin + ConnectionService) with video, lock control, history.
- Integration and testing — test bench with a real intercom, latency checks, error scenarios.
- Publishing to App Store and Google Play — provisioning profiles, code signing, push certificates.
Development Phases
| Phase | Content | Timeline |
|---|---|---|
| Hardware audit and architecture | Device protocols, stack selection | 3-5 days |
| Server side | Asterisk/WebRTC server, API | 1-2 weeks |
| Mobile client iOS + Android | CallKit, video, lock control | 2-3 weeks |
| Event recording and history | S3, player, log | 1 week |
| Testing on hardware | QA on real intercom | 1 week |
Total from 1 to 3 months depending on complexity and multi-apartment requirements.
Hardware Comparison
| Type | Protocol | Complexity | Video Latency | Vendor Lock-in |
|---|---|---|---|---|
| SIP intercom | SIP + ONVIF | Medium | 200-500 ms | No |
| Custom (RPi) | WebRTC | High | 150-400 ms | No |
| Cloud (Ring/Dahua) | P2P SDK | Low | 300-600 ms | Yes |
What's Included in the Work
Upon project completion, you receive:
- Source code for the mobile app (iOS/Android) with comments
- Built IPA/APK and publishing configurations
- Server side (if required) in Docker containers
- API documentation and deployment instructions
- 1 month of technical support after delivery
- Code in a private Git repository
If you want to evaluate your project, contact us — we will prepare a preliminary architecture and estimate within 2 business days.