Last updated: March 16, 2026

Traditional building intercom systems operate over analog lines or unencrypted digital protocols, making them vulnerable to eavesdropping and unauthorized access. For developers and power users seeking better privacy, setting up a secure intercom system using encrypted VoIP technology provides end-to-end encryption, flexible deployment options, and integration with existing network infrastructure.

This guide covers the architectural components, protocol choices, and implementation steps for building a secure VoIP-based intercom system.

Table of Contents

Understanding the Security Requirements

A secure intercom system for residential or commercial buildings must address several core security properties:

Traditional VoIP protocols like SIP can be encrypted using TLS for signaling and SRTP (Secure Real-time Transport Protocol) for media streams. This combination provides protection against eavesdropping and man-in-the-middle attacks.

Most off-the-shelf intercom systems, brands like Comelit, Aiphone, and 2N, offer some form of IP connectivity, but they often default to unencrypted SIP over port 5060. Even when TLS options exist, the configuration requires manual intervention and many installers skip it. Building your own stack from open-source components gives you verifiable security from the start.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Architectural Components

A self-hosted intercom system consists of four main components:

  1. VoIP Server - Handles call routing, authentication, and registration (e.g., Asterisk, FreeSWITCH, or a lightweight SIP proxy)
  2. Client Devices: IP phones, softphones, or dedicated intercom hardware at each entry point
  3. Network Infrastructure: Local network with VLAN segmentation for security isolation
  4. Encryption Layer: TLS for SIP signaling and SRTP for audio streams

For building applications, the most practical approach uses a lightweight SIP proxy combined with encrypted softphones running on low-cost hardware like Raspberry Pi devices equipped with USB microphones and speakers.

Choosing Between Asterisk and FreeSWITCH

Asterisk is the more widely documented option and has a larger community, making it the better choice if you are starting from scratch. FreeSWITCH handles higher call volumes more efficiently but has a steeper configuration learning curve. For a building intercom system that will serve 5-50 concurrent users, Asterisk running on a Raspberry Pi 4 or a basic VPS is more than sufficient.

Kamailio is a third option worth knowing, it functions as a pure SIP proxy/registrar without media handling. Pairing Kamailio with RTPengine for media relay gives you a highly scalable setup, but for a residential or small commercial intercom system, the added complexity is unnecessary.

Step 2 - Choose VoIP Protocols and Encryption Standards

SIP with TLS Transport

The Session Initiation Protocol (SIP) handles call setup, teardown, and negotiation. By default, SIP traffic travels in plaintext. Enabling TLS transport encrypts the signaling layer:

Example Asterisk configuration for TLS-enabled SIP
[general]
tlsenable=yes
tlsbindaddr=0.0.0.0:5061
tlscertfile=/etc/asterisk/asterisk.pem
tlscafile=/etc/asterisk/ca.crt
tlscipher=ALL
tlsclientmethod=tlsv1.2

[intercom-user]
type=peer
secret=secure_password_here
host=dynamic
transport=tls
context=intercom-incoming

SRTP for Media Encryption

Secure Real-time Transport Protocol encrypts the actual audio stream. Both endpoints must support SRTP and negotiate the encryption keys during call establishment:

Enable SRTP in Asterisk
[general]
rtpdebug=yes

[intercom-user]
type=peer
secret=secure_password_here
host=dynamic
transport=tls
encryption=yes

When configuring client devices, ensure SRTP is set to mandatory rather than optional. This prevents fallback to unencrypted RTP if negotiation fails. Many SIP phones and softphones silently fall back to plaintext RTP when SRTP negotiation fails, mandatory mode causes the call to drop instead, which is the correct behavior for a security-focused setup.

Generating Certificates for SIP TLS

Use a self-signed certificate for a closed intercom system, or Let’s Encrypt if your SIP server has a public hostname:

Generate a self-signed certificate for Asterisk
openssl req -new -x509 -days 365 -nodes \
  -out /etc/asterisk/asterisk.pem \
  -keyout /etc/asterisk/asterisk.pem \
  -subj "/CN=mail.yourdomain.com"

Combine cert and key (Asterisk expects them in one file)
cat asterisk.key >> asterisk.pem
chmod 640 /etc/asterisk/asterisk.pem
chown asterisk:asterisk /etc/asterisk/asterisk.pem

If using Let’s Encrypt, install certbot and create a deploy hook that copies the renewed certificate to Asterisk’s config directory and restarts the service.

Step 3 - Set Up a Lightweight SIP Proxy

For building intercom applications where full telephony features are unnecessary, a lightweight SIP proxy like SIP.js or Kamailio provides sufficient functionality with lower resource requirements.

Using a Minimal Docker-based Setup

A minimal self-hosted intercom server can run in Docker containers:

Dockerfile for minimal SIP proxy
FROM debian:bookworm-slim

RUN apt-get update && apt-get install -y \
    opensips \
    && rm -rf /var/lib/apt/lists/*

RUN mkdir -p /etc/opensips && \
    echo "listen=tls:0.0.0.0:5061" >> /etc/opensips/opensips.cfg && \
    echo "modparam(\"auth\", \"username_spec\", \"intercom\")" >> /etc/opensips/opensips.cfg

EXPOSE 5061

CMD ["/usr/sbin/opensips", "-F"]

Docker Compose configuration
version: '3.8'
services:
  opensips:
    build: .
    ports:
      - "5061:5061/tls"
    volumes:
      - ./opensips.cfg:/etc/opensips/opensips.cfg
    networks:
      - intercom-net

  asterisk:
    image: asterisk:latest
    volumes:
      - ./asterisk:/etc/asterisk
    network_mode: host
    depends_on:
      - opensips

networks:
  intercom-net:
    driver: bridge

Step 4 - Client Implementation Patterns

Hardware Intercom Devices

For physical entry points (building doors, lobby), use IP phones or SIP-enabled intercom hardware. Many VoIP door phones support PoE (Power over Ethernet) and can be provisioned via configuration files:

<!-- Example SIP device configuration -->
<sip>
  <server>192.168.1.10:5061</server>
  <transport>TLS</transport>
  <username>door_unit_1</username>
  <password>encrypted_password_here</password>
  <srtp>mandatory</srtp>
  <codecs>opus,g722,pcmu</codecs>
</sip>

The 2N IP Verso and Grandstream GDS3710 are widely used SIP door stations that support TLS/SRTP out of the box. Both offer PoE powering, wide-angle cameras, and card reader inputs, useful if you want to integrate access control with your intercom calls. The Grandstream is substantially cheaper but has a less polished configuration UI.

Softphone Clients for Residents

Residents can use softphones on smartphones or computers. Linphone, CSipSimple, and MicroSIP all support TLS and SRTP. Configure profiles for your building’s SIP server:

Linphone configuration for secure intercom
linphonecsh init
linphonecsh register --host 192.168.1.10 --port 5061 --username resident_101 --transport tls

On iOS, Linphone and Groundwire both support SRTP. On Android, Linphone is the most actively maintained open-source option. For desktop clients, Zoiper and MicroSIP offer better UI polish than Linphone on Windows, and both support mandatory SRTP.

Network Security Considerations

Deploying a secure intercom system requires proper network segmentation:

  1. Create a dedicated VLAN for intercom devices, isolating them from general network traffic
  2. Configure firewall rules to allow only necessary traffic between the intercom VLAN and the server
  3. Disable unnecessary services on intercom devices
  4. Use certificate-based authentication rather than shared secrets where possible
Example iptables rules for intercom VLAN
Allow SIP traffic only from intercom VLAN to server
iptables -A INPUT -p tcp --dport 5061 -s 192.168.50.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5061 -j DROP

Allow RTP traffic from intercom devices
iptables -A INPUT -p udp --dport 10000:20000 -s 192.168.50.0/24 -j ACCEPT

RTP Port Range

RTP media streams use ephemeral UDP ports. In Asterisk, the default range is 10000-20000. Configure this in /etc/asterisk/rtp.conf:

[general]
rtpstart=10000
rtpend=10100

Narrowing the range to 10000-10100 limits your firewall exposure while still supporting up to 50 simultaneous calls. Adjust the upper bound based on your expected concurrent call volume, each active call consumes two ports (one for audio, one for RTCP).

Step 5 - Test Encryption

After deployment, verify that encryption is properly configured. Use tools like sngrep to capture SIP traffic and confirm TLS is active:

Install and run sngrep to verify TLS
sudo apt-get install sngrep
sudo sngrep -l

Look for SIP messages traveling over port 5061 with TLS indicator. For SRTP verification, examine the SDP (Session Description Protocol) offers to confirm RTP/SAVPF profile usage, which indicates SRTP is negotiated.

You can also use Wireshark with a TLS decryption key to inspect the full SIP conversation. If you see a=crypto: lines in the SDP body and RTP/SAVP in the media description, SRTP is active. A call that shows only RTP/AVP is falling back to unencrypted media.

For a quick sanity check, run a test call while capturing traffic with tcpdump:

sudo tcpdump -i eth0 -w /tmp/sip-capture.pcap port 5061 or udp portrange 10000-10100

Open the capture in Wireshark and check that the SIP signaling on port 5061 shows as TLS-encrypted (you will not be able to decode the contents without the key, which is a good sign). The UDP media packets should not decode as RTP if SRTP is active correctly.

Step 6 - Dial Plan Configuration

Configure Asterisk’s extensions.conf to route door unit calls to residents:

[intercom-incoming]
; Door unit calls ring all residents in apartment 101
exten => door_unit_1,1,Dial(SIP/resident_101,30)
exten => door_unit_1,n,Hangup()

; Door release tone triggers relay via GPIO or HTTP API
exten => door_release,1,System(/usr/local/bin/trigger-door-release.sh)
exten => door_release,n,Hangup()

Many door stations support a relay output that can be triggered by sending a DTMF tone during the call. The Asterisk dial plan above can be extended to detect DTMF tones and invoke a script that calls the door station’s HTTP API to release the lock.

Step 7 - Perform Maintenance and Monitoring

Regular maintenance ensures continued security:

Check Asterisk TLS certificate expiration
openssl x509 -in /etc/asterisk/asterisk.pem -noout -dates

Monitor the Asterisk security log at /var/log/asterisk/security for repeated failed registration attempts. Failed attempts from external IPs indicate that your SIP server is being probed. Fail2Ban can be configured to ban IPs after a threshold of failed SIP registrations, the fail2ban-jail.conf package for Asterisk is available in most distributions.

Set up log rotation so Asterisk logs do not fill the disk:

/etc/logrotate.d/asterisk
/var/log/asterisk/*.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        /usr/sbin/asterisk -rx 'logger reload' > /dev/null 2>&1
    endscript
}

Troubleshooting

Configuration changes not taking effect

Restart the relevant service or application after making changes. Some settings require a full system reboot. Verify the configuration file path is correct and the syntax is valid.

Permission denied errors

Run the command with sudo for system-level operations, or check that your user account has the necessary permissions. On macOS, you may need to grant terminal access in System Settings > Privacy & Security.

Connection or network-related failures

Check your internet connection and firewall settings. If using a VPN, try disconnecting temporarily to isolate the issue. Verify that the target server or service is accessible from your network.

Frequently Asked Questions

How long does it take to set up secure intercom system using encrypted voip?

For a straightforward setup, expect 30 minutes to 2 hours depending on your familiarity with the tools involved. Complex configurations with custom requirements may take longer. Having your credentials and environment ready before starting saves significant time.

What are the most common mistakes to avoid?

The most frequent issues are skipping prerequisite steps, using outdated package versions, and not reading error messages carefully. Follow the steps in order, verify each one works before moving on, and check the official documentation if something behaves unexpectedly.

Do I need prior experience to follow this guide?

Basic familiarity with the relevant tools and command line is helpful but not strictly required. Each step is explained with context. If you get stuck, the official documentation for each tool covers fundamentals that may fill in knowledge gaps.

Is this approach secure enough for production?

The patterns shown here follow standard practices, but production deployments need additional hardening. Add rate limiting, input validation, proper secret management, and monitoring before going live. Consider a security review if your application handles sensitive user data.

Where can I get help if I run into issues?

Start with the official documentation for each tool mentioned. Stack Overflow and GitHub Issues are good next steps for specific error messages. Community forums and Discord servers for the relevant tools often have active members who can help with setup problems.

Related Articles