Voip-Homelab

VoIP Home Lab Reference
Lab Overview · Introduction

VoIP Home Lab

A complete unified communications environment built from the ground up for hands-on learning and real-world practice.

Why this lab exists

This lab bridges the gap between CCNA networking theory and real-world VoIP deployment. It demonstrates how Layer 2/3 concepts, VLANs, QoS, and NAT interact in a production telephony environment.

Physical Hardware Inventory

Arris TG3452A

ISP-provided cable modem in bridge mode

Bridge mode passes public IP to the ER605, disabling NAT and routing functions. Essential for proper VoIP NAT traversal.

TP-Link ER605 V2

Main router handling inter-VLAN routing

Omada SDN-compatible router. Manages DHCP for all VLANs, ACLs between networks, WireGuard VPN, and DDNS updates.

Cisco Catalyst 3750-48PS-S

L3 switch with 802.1Q trunking and PoE

48-port managed switch with 802.3af PoE on all ports. Handles VLAN segmentation, QoS marking, and SPAN port for packet capture.

Yealink SIP-T21P E2

Two IP desk phones

Entry-level enterprise IP phones with PoE support. Configured with extensions 1001 and 1002. Originally on VLAN 20, moved to VLAN 10.

Debian 12 Server

FreePBX host on Dell OptiPlex

Runs FreePBX 17 (Asterisk 20) in Docker. Also hosts Homer SIP capture. IP: 192.168.10.100 on VLAN 10.

Raspberry Pi 5

LibreNMS monitoring server

Runs LibreNMS with SNMP polling of all network devices. IP: 192.168.0.101 on Management VLAN.

Logical Network Map

VLANPurposeSubnetGateway
VLAN 1Management192.168.0.0/24192.168.0.1
VLAN 10Data192.168.10.0/24192.168.10.1
VLAN 20VoIP192.168.20.0/24192.168.20.1

IP Address Reference

DeviceIP AddressVLANNotes
TP-Link ER605192.168.0.1ManagementRouter, DHCP server
Cisco 3750192.168.0.2ManagementSwitch SVI
FreePBX Server192.168.10.100DataDebian 12 + Docker
LibreNMS (Pi 5)192.168.0.101ManagementMonitoring
Yealink Phone 1192.168.10.101DataExt 1001
Yealink Phone 2192.168.10.102DataExt 1002
Homer SIP Capture127.0.0.1:9060LocalhostDocker container
Lab Overview · Topology

Network Diagram

Visual representation of the complete VoIP lab topology, including VLAN segmentation and SIP trunk connection.

Complete network topology showing ISP connectivity, VLAN segmentation, and device placement

Diagramming Decisions

ElementRepresentationRationale
SIP Trunk LinesDashed linesIndicates logical/virtual connection, not physical cable
ISP CloudCloud iconImplies continuation beyond the diagram boundary
VLAN BoxesBackground shadingVisual grouping of devices in same broadcast domain
Trunk Link802.1Q labelIndicates tagged VLAN traffic on that port

Port Reference: Fa1/0/48 is the trunk port connecting Cisco 3750 to TP-Link ER605. Fa1/0/25 connects to Yealink phones (when on VLAN 20), Fa1/0/13 connects to FreePBX server.

VoIP Theory · Protocols

SIP Fundamentals

Understanding the Session Initiation Protocol and its role in modern VoIP communications.

SIP Protocol Deep Dive

SIP is signaling-only — it sets up, modifies, and tears down calls. It does not carry audio. SIP is a text-based protocol (similar to HTTP) that operates on UDP/TCP port 5060.

SIP (Session Initiation Protocol)

Text-based signaling protocol operating on UDP/TCP port 5060

What it does:
• Sets up, modifies, and tears down sessions
• Handles registration, authentication, call routing
• Negotiates media parameters via SDP
• Routes calls to endpoints and trunks

Analogy: The postal service delivering call setup instructions

RTP (Real-time Transport Protocol)

Binary protocol carrying actual voice/video packets on dynamic UDP ports

What it does:
• Transports actual voice packets directly between endpoints
• Bypasses the PBX once the call is established
• Provides sequence numbers and timestamps
• RTCP companion provides QoS feedback

Analogy: The actual phone line carrying your voice

SDP: Session Description Protocol

SDP travels inside SIP and negotiates codecs and RTP ports. When a phone sends an INVITE, it includes an SDP body describing:

  • Codecs supported: G.711 μ-law, G.729, etc.
  • RTP port: Where to send audio (e.g., port 10004)
  • IP address: Where the media should be sent
# SDP excerpt from INVITE body
v=0
o=- 12345 12345 IN IP4 192.168.10.101
s=Yealink call
c=IN IP4 192.168.10.101
t=0 0
m=audio 10004 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

RTCP: Real-time Transport Control Protocol

RTCP is RTP’s companion protocol that monitors stream quality. It reports on:

  • Jitter: Variation in packet arrival timing
  • Packet loss: Percentage of lost packets
  • MOS score: Mean Opinion Score (voice quality rating)
  • Round-trip time: Latency measurement
The separation of concerns

SIP handles the “business logic” of calls (who, where, when), while RTP/RTCP handle the “physics” of audio (how, what quality). This separation is why SIP phones can register through a PBX, but RTP streams flow directly between endpoints.

The B2BUA Model

FreePBX/Asterisk acts as a Back-to-Back User Agent — this is critical to understanding SIP call flows.

Why B2BUA matters

A B2BUA terminates and re-originates SIP sessions. For every call, there are two INVITE legs: one from caller to PBX, one from PBX to callee. This allows the PBX to manipulate headers, enforce policies, and bridge incompatible endpoints.

Typical Call Flow

Phone A (1001)                FreePBX                Phone B (1002)
     |                             |                         |
     |---- INVITE (to PBX) -------->|                         |
     |<--- 100 Trying --------------|                         |
     |<--- 180 Ringing -------------|                         |
     |                             |---- INVITE (to 1002) --->|
     |                             |<--- 100 Trying ----------|
     |                             |<--- 180 Ringing ---------|
     |<--- 180 Ringing (relayed) ---|                         |
     |                             |<--- 200 OK --------------|
     |<--- 200 OK (relayed) --------|                         |
     |---- ACK -------------------->|---- ACK ---------------->|
     |<=== RTP Media =============>|<=== RTP Media ==========>|
     |                             |                         |
VoIP Theory · NAT Traversal

NAT Traversal

Why Network Address Translation breaks SIP, and comprehensive solutions.

The Core Problem

When a phone behind NAT puts a private IP in the SDP body, the remote side can’t send RTP back — causing one-way audio. SIP embeds IP addresses inside message bodies (SDP), not just headers. When NAT rewrites packet headers, the body remains unchanged — causing a mismatch.

The NAT mismatch

Scenario: Internal phone (192.168.10.101) sends INVITE with SDP containing its private IP. Provider receives public NAT IP in headers but private IP in SDP body. RTP returns to wrong destination.

NAT Traversal Solutions

Disable SIP ALG

First and most important step on the router

SIP ALG attempts to “help” by rewriting SIP bodies but usually corrupts them. Disable it in router settings (Advanced → NAT → SIP ALG → Off).

External IP in FreePBX

Configure NAT settings in Asterisk SIP Settings

Set External Address to your public IP. This tells Asterisk to rewrite SDP with the correct public address when sending to external peers.

STUN Server

Helps endpoints discover their public IP

Phone queries STUN server (e.g., stun.l.google.com:19302), receives public address, uses that in SDP.

RTP Port Range

Open UDP 10000–20000 on the firewall

Asterisk uses this range for RTP media. These must be forwarded to the PBX or allowed through the firewall.

STUN: Session Traversal Utilities for NAT

STUN allows endpoints to discover their public IP and port mappings. The phone queries a STUN server, receives its public address, and uses that in SDP.

# STUN request/response flow
Phone → STUN server (stun.l.google.com:19302): “What’s my public IP?”
STUN server → Phone: “Your public address is 203.0.113.45:51234”

From Domain Fix

For VoIP.ms trunk, the From Domain setting in FreePBX forces the correct public identity in SIP headers. This ensures the provider recognizes the registration and routes inbound calls correctly.

Configuration: In FreePBX PJSIP trunk settings, set “From Domain” to newyork1.voip.ms to match your POP (Point of Presence).

SIP ALG: The Silent Killer

SIP Application Layer Gateway attempts to fix NAT issues by rewriting SIP bodies. In practice, it often:

  • Mangles SDP with incorrect IP addresses
  • Breaks SIP message integrity
  • Causes intermittent registration failures
  • Corrupts packet payloads

Best Practice: Disable SIP ALG on all routers/firewalls. Use proper NAT configuration in the PBX instead.

UDP Session Timeouts

Routers maintain UDP “connections” in state tables. When idle, these entries expire. VoIP phones send periodic OPTIONS or re-REGISTER to keep sessions alive. When phones were moved to VLAN 10 (same subnet as FreePBX), session timeout issues disappeared because traffic no longer traversed the router.

VoIP Theory · Quality of Service

QoS Theory

Voice traffic needs guaranteed low-latency forwarding to maintain call quality.

Why QoS is Essential

Voice traffic is uniquely sensitive to network conditions. Without QoS, data traffic (file transfers, streaming) can starve voice packets, causing choppy audio and dropped calls.

The problem without QoS

A large file download can saturate your bandwidth. Without prioritization, voice packets queue behind data packets, causing delay and jitter. QoS ensures voice gets priority treatment.

Layer 2: CoS (Class of Service)

CoS uses the 802.1p field in the Ethernet frame to mark priority at Layer 2.

CoS ValueTraffic TypeUse Case
5Voice Bearer (RTP)Highest priority for actual voice packets
3Voice Signaling (SIP)Second priority for call setup/control
1Best EffortStandard data traffic
0DefaultUnmarked traffic
# Cisco: Trust CoS markings from IP phones
Switch(config-if)# mls qos trust cos

Layer 3: DSCP (Differentiated Services Code Point)

DSCP uses the 6-bit field in the IP header for priority marking. It’s more granular than CoS and survives across Layer 3 boundaries.

DSCP ValueNameTraffic Type
EF (46)Expedited ForwardingRTP voice media
AF31 (26)Assured ForwardingSIP signaling
CS0 (0)Class SelectorBest effort data
# Cisco: Trust DSCP markings (common for VoIP)
Switch(config-if)# mls qos trust dscp

QoS Implementation Best Practices

  • Trust, don’t remark: IP phones already mark correctly; just trust their markings
  • Apply at the edge: Set QoS policies at access ports where phones connect
  • End-to-end: QoS markings must be honored throughout the network path
  • WAN links: Most critical point — prioritize before traffic leaves the building
VoIP Theory · Segmentation

VLAN Theory

Voice must be isolated on its own VLAN for security, QoS, and performance.

Why Voice Needs Its Own VLAN

  • QoS Policies: Apply different quality-of-service rules to voice vs. data
  • Reduced Broadcast Domain: Smaller broadcast domains improve performance
  • Security: Isolate voice traffic from data network sniffing
  • Prevent Competition: Stop data traffic from competing with voice bandwidth

switchport voice vlan

The switchport voice vlan command signals the phone via CDP/LLDP to tag its voice frames. The phone separates voice and PC traffic onto different VLANs using the same physical cable.

# Cisco: Configure voice VLAN on access port
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport voice vlan 20

DHCP Option 66: Zero-Touch Provisioning

DHCP Option 66 enables zero-touch provisioning by pointing phones to a provisioning server (TFTP/HTTP) on boot. The phone automatically downloads its configuration.

# DHCP Option 66 configuration example
option 66 ascii “http://192.168.10.100/provisioning”

LLDP-MED (Link Layer Discovery Protocol – Media Endpoint Discovery)

LLDP-MED is an extension of LLDP that allows network devices to advertise:

  • Voice VLAN ID
  • QoS configuration
  • Power over Ethernet (PoE) requirements
VoIP Theory · Quality Metrics

RTP Quality Thresholds

Accepted benchmarks for acceptable voice quality.

Voice Quality Benchmarks

MetricAcceptableExcellentNotes
Jitter< 30ms< 10msVariation in packet arrival
Packet Loss< 1%< 0.1%Causes audio gaps
Latency (one-way)< 150ms< 50msRound-trip < 300ms
MOS Score> 3.5> 4.0Mean Opinion Score (1-5)

MOS Score (Mean Opinion Score)

MOS is a subjective quality rating from 1 to 5, where listeners rate voice quality. It’s calculated based on network metrics:

  • 5.0: Excellent — Face-to-face conversation quality
  • 4.0-4.5: Good — Toll quality (PSTN standard)
  • 3.5-4.0: Acceptable — Minor impairment
  • 3.0-3.5: Fair — Noticeable degradation
  • < 3.0: Poor — Unacceptable for business use

Factors Affecting Voice Quality

Jitter

Variation in packet arrival time

Packets arriving at irregular intervals cause audio distortion. Jitter buffers can compensate but add latency.

Packet Loss

Missing audio data

Even 1% loss causes noticeable gaps. Packet loss concealment (PLC) algorithms can mask small losses.

Latency

One-way delay

Over 150ms makes conversation awkward with talk-over. Over 300ms is unusable for real conversation.
VoIP Theory · PBX Architecture

FreePBX / Asterisk Architecture

Understanding how the PBX routes and processes calls.

Core Components

Extensions (chan_pjsip)

Endpoints that register to the PBX

IP phones and softphones register using SIP. chan_pjsip is the modern channel driver replacing legacy chan_sip.

Trunks

Connections to the PSTN

SIP trunks connect to VoIP providers (VoIP.ms, etc.) for inbound/outbound calling to the public telephone network.

Inbound Routes

Match incoming DIDs to destinations

When a call arrives from a trunk, inbound routes match the DID and route to an extension, IVR, ring group, or queue.

Outbound Routes

Match dial patterns to trunks

Outbound routes define which trunk to use based on the dialed number pattern (e.g., 911 routes to emergency trunk, 1NXXNXXXXXX to VoIP.ms).

Call Routing Logic

FeaturePurpose
IVRInteractive Voice Response — menu systems (“Press 1 for Sales”)
Ring GroupsSimultaneously ring multiple extensions
QueuesACD (Automatic Call Distribution) with hold music
Time ConditionsRoute calls differently based on time/date
Follow MeForward calls to external numbers
VoicemailMessage recording with email notification

Call Flow Example

Incoming Call (DID 814-667-5639)
       ↓
  Inbound Route (matches DID)
       ↓
  Time Condition (business hours?)
       ↓
  IVR ("Thank you for calling...")
       ↓
  Ring Group (ext 1001, 1002)
       ↓
  Extension rings → Answer
       ↓
  RTP stream established
VoIP Theory · Legacy Infrastructure

Analog / POTS

Understanding legacy telephony infrastructure and migration to VoIP.

FXS vs FXO Ports

TypeFull NameFunctionAnalogy
FXSForeign Exchange StationPowers the phone, provides dial toneThe wall jack in your house
FXOForeign Exchange OfficeConnects to the PSTNThe phone cable you plug into the wall

Memory trick: FXS = Serves the phone (provides power and dial tone). FXO = connects to the Office (PSTN).

Wiring Infrastructure

66-Blocks

Legacy punch-down blocks

Still found in older buildings. Used to cross-connect copper pairs. Being phased out in favor of 110-blocks.

110-Blocks

Modern punch-down standard

The current standard for terminating twisted-pair cabling. More compact and easier to work with than 66-blocks.

Tone and Probe

“Fox and Hound” cable tracing

Used to trace copper pairs from wall jacks to wiring closets without physical connection. The tone generator sends a signal; the probe detects it.

Migrating from POTS to VoIP

When migrating legacy systems:

  • Identify all analog lines (fax, alarms, elevator phones)
  • Plan for ATA (Analog Telephone Adapter) or gateway devices
  • Test fax machines — they often have issues with VoIP
  • Ensure emergency lines (elevator, alarm) remain functional
VoIP Theory · Signaling

SIP Response Codes

Understanding what SIP responses mean and how to troubleshoot them.

Response Code Categories

RangeCategoryMeaning
1xxInformationalCall is progressing
2xxSuccessRequest succeeded
3xxRedirectionAlternative location
4xxClient ErrorSomething wrong with the request
5xxServer ErrorServer failed to process valid request
6xxGlobal FailureNo server can fulfill the request

Common Response Codes

CodeNameMeaning / Troubleshooting
100TryingNormal — server received request and is processing
180RingingNormal — destination is ringing
200OKSuccess — call connected or registration accepted
401UnauthorizedAuth challenge — credentials required (normal during registration)
403ForbiddenBad credentials or blocked IP — check password and ACLs
404Not FoundExtension not found — check extension number exists
408Request TimeoutUnreachable — network issue or phone offline
486Busy HereDestination busy — phone in use
488Not AcceptableCodec mismatch — no common codec between endpoints
503Service UnavailableServer unavailable — trunk down or PBX overloaded

Troubleshooting by Code

401 Loop

Continuous 401 responses

Phone sends REGISTER → 401 → Phone sends credentials → 401 again. Check that the phone is actually sending credentials and that the secret matches.

488 Codec Mismatch

No common audio codec

Phone supports G.729 only, PBX offers G.711 only. Enable a common codec in both endpoints.
Network · Infrastructure

Network Configuration

VLAN setup, trunking, and inter-VLAN routing configuration.

802.1Q Trunking on Cisco 3750

Port Fa1/0/48 connects to the TP-Link ER605 and carries all VLANs as a trunk.

Switch(config)# interface FastEthernet1/0/48
Switch(config-if)# description “Trunk to ER605”
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 1,10,20
Switch(config-if)# no shutdown

Why Trunking is Necessary

A single physical link carries multiple logical networks. Without trunking, each VLAN would need its own cable to the router. The TP-Link ER605 subinterfaces handle routing between VLANs.

VLAN Port Assignments

Port RangeVLANPurpose
Fa1/0/1 – 121Management devices
Fa1/0/13 – 2410Data network
Fa1/0/25 – 4720VoIP (unused – phones moved to VLAN 10)
Fa1/0/48TrunkUplink to router

Inter-VLAN Routing

The TP-Link ER605 handles Layer 3 routing between VLANs:

  • Router: Maintains routing table, forwards between subnets
  • Switch: Pure Layer 2 switching within each VLAN

ACL Limitation: TP-Link ACLs control inter-VLAN traffic at Layer 3. They do NOT apply to same-subnet Layer 2 traffic. This is why phones on VLAN 10 can reach FreePBX directly without ACL involvement.

Network · Remote Access

WireGuard VPN & DDNS

Secure remote access configuration for managing the lab from anywhere.

NO-IP DDNS Configuration

Dynamic DNS keeps a consistent hostname despite changing public IP addresses.

SettingValue
Hostnamecharliehomelab.ddns.net
ProviderNO-IP (noip.com)
Update IntervalEvery 5 minutes
PurposeConsistent endpoint for VPN connections

WireGuard VPN Setup

WireGuard provides encrypted tunnel access to the lab network from remote locations.

VPN Subnet

10.200.200.0/24

Dedicated VPN subnet does not overlap with any internal VLANs. Clients receive IPs in this range when connected.

Allowed IPs

192.168.0.0/16, 10.0.0.0/8

Split tunnel configuration. Only lab traffic routes through VPN; internet traffic uses local connection.

DNS

192.168.0.1 (ER605)

VPN clients use the router for DNS resolution, enabling access to internal hostnames.

Configuration Purpose

  • Secure Management: Access FreePBX GUI, SSH, and switch CLI remotely
  • SIP Softphone: Run softphone apps that register as internal extensions
  • Packet Capture: Remote SPAN session analysis via WireGuard
Network · Remote Access

WireGuard VPN & DDNS

Secure remote access configuration for managing the lab from anywhere.

NO-IP DDNS Configuration

Dynamic DNS keeps a consistent hostname despite changing public IP addresses.

SettingValue
Hostnamecharliehomelab.ddns.net
ProviderNO-IP (noip.com)
Update IntervalEvery 5 minutes
PurposeConsistent endpoint for VPN connections

WireGuard VPN Setup

WireGuard provides encrypted tunnel access to the lab network from remote locations.

VPN Subnet

10.200.200.0/24

Dedicated VPN subnet does not overlap with any internal VLANs. Clients receive IPs in this range when connected.

Allowed IPs

192.168.0.0/16, 10.0.0.0/8

Split tunnel configuration. Only lab traffic routes through VPN; internet traffic uses local connection.

DNS

192.168.0.1 (ER605)

VPN clients use the router for DNS resolution, enabling access to internal hostnames.

Configuration Purpose

  • Secure Management: Access FreePBX GUI, SSH, and switch CLI remotely
  • SIP Softphone: Run softphone apps that register as internal extensions
  • Packet Capture: Remote SPAN session analysis via WireGuard
FreePBX · Setup

FreePBX Configuration

Core Asterisk setup, extensions, and system configuration.

Extension Setup

Two extensions configured for the Yealink phones:

ExtensionUserPhoneSecret Type
1001Line 1Yealink T21P E2SIP
1002Line 2Yealink T21P E2SIP

Phone Registration Process

  1. Phone boots and requests IP via DHCP (VLAN 10)
  2. Phone sends REGISTER to FreePBX (192.168.10.100:5060)
  3. FreePBX challenges with 401 Unauthorized (digest auth)
  4. Phone responds with credentials
  5. FreePBX accepts and updates AOR (Address of Record)

The delete=yes Voicemail Bug

The Bug

Voicemail.conf had delete=yes set, causing messages to be deleted immediately after recording — before email notification could be sent. Messages appeared to be silently discarded.

How it was caught: sngrep showed successful SIP INVITE/200 OK flow to voicemail, but no message was playable. Log analysis revealed the file was deleted before the email handler processed it.

The fix: Changed to delete=no in voicemail.conf, allowing the message to persist after email delivery.

FreePBX · SIP Trunking

VoIP.ms SIP Trunk

Connecting to the public telephone network via VoIP.ms.

VoIP.ms Account Structure

ComponentValuePurpose
Main AccountcharliechenBilling and primary login
Sub-accountcharliechen_homepbxSIP registration endpoint
DID814-667-5639Public phone number
POPnewyork1.voip.msPoint of Presence

PJSIP Trunk Configuration

# FreePBX PJSIP Trunk Settings

Username: charliechen_homepbx
Secret: [redacted]
SIP Server: newyork1.voip.ms
SIP Server Port: 5060
From Domain: newyork1.voip.ms
From User: charliechen_homepbx
Transport: 0.0.0.0-udp
Match Permit: 208.100.60.0/24

Key Settings Explained

  • From Domain: Ensures provider recognizes the registration origin
  • Match Permit: Restricts inbound calls to VoIP.ms IP range
  • chan_pjsip: Modern SIP channel driver replacing legacy chan_sip
FreePBX · Security

Firewall & fail2ban

Securing the VoIP server against attacks and unauthorized access.

FreePBX Firewall Module Disabled

The integrated firewall module was disabled due to a compatibility issue with Debian 12.

Debian 12 iptables Issue

FreePBX firewall uses iptables --wait-interval which behaves differently in Debian 12’s iptables version. This caused a crash loop where the firewall would restart, fail, and restart continuously.

Solution: Manage iptables directly without the FreePBX module.

Direct iptables Management

# Essential iptables rules for VoIP

$ iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -p udp –dport 5060 -j ACCEPT
$ iptables -A INPUT -p udp –dport 10000:20000 -j ACCEPT
$ iptables -A INPUT -p tcp –dport 80 -j ACCEPT
$ iptables -A INPUT -p tcp –dport 443 -j ACCEPT
$ iptables -A INPUT -p tcp –dport 22 -s 192.168.0.0/16 -j ACCEPT
$ iptables -P INPUT DROP

fail2ban Configuration

fail2ban monitors logs and bans IPs showing malicious patterns (brute force, scanning).

Essential jail.local Whitelist Entries

# /etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 127.0.0.1/8 192.168.0.0/16 10.0.0.0/8 \
208.100.60.0/24
Whitelisted RangeReason
192.168.0.0/16Internal networks – never ban local devices
10.0.0.0/8VPN subnet for remote access
208.100.60.0/24VoIP.ms servers – registration traffic
Why whitelisting matters

Without VoIP.ms IPs whitelisted, legitimate registration traffic can trigger fail2ban (especially during re-registration storms). This caused Scenario 1: phones failing to register after a power cycle when fail2ban auto-banned the VoIP.ms IP.

Monitoring · Diagnostics

Packet Capture & SIP Analysis

Tools and techniques for analyzing VoIP traffic.

Cisco SPAN Session

Switched Port Analyzer (SPAN) mirrors traffic from source ports to a destination for capture.

Switch(config)# monitor session 1 source interface Fa1/0/13 – 24
Switch(config)# monitor session 1 destination interface Fa1/0/1
Switch(config)# monitor session 1 encapsulation dot1q
SettingValuePurpose
SourceFa1/0/13-24FreePBX and phone ports
DestinationFa1/0/1Laptop running Wireshark
Encapsulationdot1qPreserve VLAN tags in capture

sngrep: Terminal SIP Analysis

sngrep is a terminal-based SIP flow viewer — essential for quick diagnostics without GUI tools.

$ sngrep
# Launch interactive SIP ladder view

$ sngrep -r # Show RTP stream analysis
$ sngrep -c # Capture mode

Reading a SIP Ladder

  • Horizontal flow: Time progression left-to-right
  • Vertical lines: Each SIP endpoint (phones, PBX, provider)
  • Arrows: SIP messages between endpoints
  • Colors: Request vs. response, success vs. error

tcpdump on FreePBX

Capture directly on the FreePBX server when SPAN isn’t available:

# Capture SIP traffic on FreePBX
$ tcpdump -i eth0 -w capture.pcap port 5060

# Capture RTP traffic (verbose)
$ tcpdump -i eth0 port 10000:20000 -v

Wireshark Telephony Features

Wireshark provides specialized VoIP analysis tools:

  • Telephony → VoIP Calls → Flow Sequence: Shows the full call ladder diagram
  • Telephony → RTP → RTP Streams: Shows jitter, loss, and MOS per call
  • Statistics → Flow Graph: Visual representation of packet flow
  • Telephony → SIP: Filter and analyze SIP traffic specifically

Wireshark Filters

# Essential Wireshark display filters

sip # All SIP traffic
rtp || rtcp # Media streams
sip.Method == “INVITE” # Call setups only
ip.addr == 192.168.10.100 # Specific host
sip.Status-Code == 401 # Auth challenges

Homer SIP Capture

Homer provides web-based SIP capture and analysis with HEP protocol.

Deployment

Docker on FreePBX machine (x86_64)

Homer runs in Docker alongside FreePBX. Docker Compose configures Homer, Heplify, and MySQL containers. Accessible at http://192.168.10.100:9080

HEP Protocol

Homer Encapsulation Protocol

Asterisk forwards SIP packets to 127.0.0.1:9060 via HEP. Heplify captures these and stores them in Homer for web viewing.
Raspberry Pi ARM64 Issue

Homer was originally attempted on Raspberry Pi 5 but failed because Docker images are x86_64 only. No ARM64 builds available. Moved Homer to FreePBX server (x86_64 Debian).

Monitoring · SNMP

LibreNMS Monitoring

Network monitoring and alerting with SNMP.

LibreNMS Deployment

Running on Raspberry Pi 5, LibreNMS polls network devices every 5 minutes and tracks:

  • Interface statistics: Bandwidth, errors, drops per port
  • CPU and memory: Switch and router utilization
  • Environmental: Temperature sensors (where available)
  • Uptime: Device availability tracking

SNMP Configuration

Switch(config)# snmp-server location “Home Lab Rack”
Switch(config)# snmp-server contact “admin@charliehomelab.ddns.net”

SNMPv2c vs. SNMPv3

VersionAuthenticationWhen to Use
SNMPv2cCommunity string onlyInternal trusted networks, simple deployments
SNMPv3User-based auth + encryptionMulti-tenant, compliance requirements, WAN exposure

SNMPv3 Configuration (Configured on 3750)

Switch(config)# snmp-server group LABGROUP v3 priv
Switch(config)# snmp-server user labuser LABGROUP v3 auth sha Password1 priv aes 128 SecretKey
ParameterValueDescription
GroupLABGROUPAccess control group
UserlabuserSNMP username
Security LevelauthPrivAuthentication + Privacy (encryption)
Auth ProtocolSHASHA-1 hashing
Priv ProtocolAES128AES 128-bit encryption
Troubleshooting · Scenarios

Troubleshooting Scenarios

Real problems encountered and their resolutions, plus systematic troubleshooting patterns.

Troubleshooting Patterns

Common symptom-to-solution mappings for VoIP issues:

SymptomCheck TheseLikely Cause
“Not Registered”Credentials, VLAN routing, FreePBX firewall, SIP ALGAuth failure, network issue, or ALG mangling
“Choppy audio”RTP jitter/loss in Wireshark, QoS configNetwork congestion, QoS not applied
“One-way audio”NAT configuration, SIP ALG, FreePBX external IPSDP contains private IP, RTP blocked
“Drops at 30 min”SIP session timer, UDP timeoutSession timer expiry, enable keepalives

Systematic Diagnostics

Not Registered

Phone shows registration failure

1. Check credentials match FreePBX extension
2. Verify VLAN routing (can phone ping PBX?)
3. Check FreePBX firewall isn’t blocking
4. Disable SIP ALG on router
5. Verify SIP port 5060 isn’t blocked

Choppy Audio

Garbled or interrupted voice

1. Check RTP jitter/loss in Wireshark
2. Verify QoS is applied on switch ports
3. Check for bandwidth saturation
4. Look for duplex mismatches
5. Verify no packet fragmentation

One-Way Audio

One party hears, other doesn’t

1. Check NAT configuration in FreePBX
2. Disable SIP ALG on router
3. Verify RTP ports open (10000-20000)
4. Check SDP for private IP addresses
5. Verify firewall isn’t blocking RTP

Call Drops at 30 Min

Consistent disconnection

1. Enable SIP session keepalives
2. Check UDP timeout on router
3. Reduce SIP session timer values
4. Enable RTP keepalive packets
5. Consider same-subnet placement

Scenario Library

1Phones Failing to Register After Power Cycle

After power outage, both Yealink phones showed “Registering…” indefinitely. Calls between extensions failed.

  • Checked phone web GUI – registration failing with “408 Request Timeout”
  • sngrep showed no SIP traffic from phones reaching PBX
  • Verified network connectivity (ping successful)
  • Checked fail2ban status: fail2ban-client status asterisk-iptables

fail2ban had auto-banned the VoIP.ms IP range (208.100.60.x) during registration attempts. Although phones register to local PBX, the ban list blocked all SIP traffic indiscriminately.

Added 208.100.60.0/24 to ignoreip in /etc/fail2ban/jail.local, then fail2ban-client unban --all and restarted phones.

Always whitelist your VoIP provider’s IP ranges in fail2ban. Provider traffic can look suspicious during re-registration storms.

2SIP Registration Instability

Phones registered briefly, then dropped. Random 401 Unauthorized errors. Registration flapping every few minutes.

  • sngrep showed mangled SIP headers
  • Via header contained wrong public IP
  • Contact header was rewritten incorrectly

SIP ALG was enabled on the TP-Link ER605. It attempted to “help” with NAT by rewriting SIP headers but corrupted them instead.

Disabled SIP ALG in router settings: Advanced → NAT → SIP ALG → Off

SIP ALG causes more problems than it solves. Disable it everywhere and handle NAT properly in the PBX.

3Calls Dropping During Idle Periods

Active calls dropped after 2-5 minutes of silence (on hold or muted). Shorter calls completed fine.

  • Packet capture showed RTP stream stopping abruptly
  • BYE came from router, not either endpoint
  • UDP session table on ER605 showed timeout values

TP-Link UDP session timeout (300 seconds) was shorter than typical call duration. Silent periods allowed NAT table entries to expire.

Moved phones to VLAN 10 (same subnet as FreePBX), eliminating NAT traversal for internal calls. For external calls, enabled RTP keepalive in Asterisk.

Keep voice traffic on same subnet when possible. When NAT is required, ensure keepalive packets maintain session state.

4Voicemail Silently Discarding Messages

Callers could leave voicemails, but no messages appeared in inbox. No email notifications sent. No error messages.

  • sngrep showed successful call to *97 voicemail
  • Asterisk logs showed voicemail recording completing
  • No email logged in Postfix queue
  • Checked voicemail.conf for delete parameter

delete=yes in voicemail.conf removed message files immediately after recording, before email handler could process them.

Changed to delete=no in voicemail.conf and reloaded Asterisk.

Delete-after-email options exist for a reason. When troubleshooting voicemail, always check the file system for .wav files.

5Homer Failing on Raspberry Pi

Homer containers continuously restarted. Web UI returned 502 Bad Gateway. Docker logs showed architecture errors.

  • docker logs homer-webapp showed exec format error
  • Checked Docker Hub – no ARM64 tags available
  • Verified Pi architecture: uname -m → aarch64

Homer Docker images are x86_64 only. No ARM64 builds for Raspberry Pi.

Moved Homer deployment to FreePBX server (x86_64 Dell OptiPlex). Retained Pi 5 for LibreNMS only.

Always verify container architecture before deployment. Don’t assume x86_64 images work on ARM.

6Switch Web GUI Authentication Failure

Switch web interface showed login prompt but rejected all credentials. CLI SSH worked fine with same credentials.

  • Verified enable secret was correct via CLI
  • Checked show ip http server status
  • Authentication method showed “local” but wasn’t applied correctly

HTTP server authentication wasn’t explicitly set to use local database.

ip http authentication local command enabled local authentication for web interface.

IOS HTTP server has separate auth configuration from VTY lines. Don’t assume they share settings.

7FreePBX Firewall Crash Loop

FreePBX GUI showed “Firewall: Error” banner. System log showed firewall restarting every 30 seconds. iptables rules not being applied.

  • Checked /var/log/asterisk/full for firewall errors
  • Found iptables –wait-interval errors
  • Compared iptables version with working FreePBX installs

Debian 12 iptables deprecated –wait-interval flag. FreePBX firewall module expected older iptables behavior.

Disabled FreePBX firewall module. Implemented direct iptables rules via /etc/iptables/rules.v4

OS upgrades can break application assumptions. Check compatibility matrices before upgrading.

8Dropped ACK Fault Simulation

In Progress

Simulate dropped SIP ACK packets to understand retransmission behavior and call setup failures.

Using iptables to drop specific SIP packets:

$ iptables -A INPUT -p udp –dport 5060 -m string –string “ACK sip:” –algo bm -j DROP

INVITE receives 200 OK, but ACK is dropped. Remote side retransmits 200 OK. Call may fail or experience delay.

Reference · CLI Commands

Command Reference

Quick lookup for commonly used commands across all platforms.

Cisco IOS

show vlan briefDisplay all VLANs and port assignments
show interface trunkShow trunk ports and allowed VLANs
show monitorDisplay SPAN session configuration
show mac address-tableView learned MAC addresses
show cdp neighborsList directly connected Cisco devices
show ip int briefInterface status and IP addresses
show running-configDisplay active configuration
write memorySave configuration to NVRAM
mls qosEnable QoS globally
mls qos trust dscpTrust DSCP markings on interface
monitor session X sourceConfigure SPAN source ports
monitor session X destConfigure SPAN destination port

Linux / Debian

iptables -L -v -nList all firewall rules with counters
iptables -FFlush all iptables rules
tcpdump -i eth0 -w cap.pcapCapture packets to file
tcpdump port 5060Capture SIP traffic
systemctl status fail2banCheck fail2ban status
fail2ban-client statusShow fail2ban jail status
fail2ban-client unban --allUnban all IP addresses
docker psList running containers
docker logs containerView container logs
ip addr showDisplay network interfaces
ss -tulnShow listening TCP/UDP ports
journalctl -u serviceView service logs

Asterisk CLI

asterisk -rvvvConnect to Asterisk console (verbose)
sip show peersList SIP endpoints and status
pjsip show endpointsList PJSIP endpoints
core show channelsDisplay active call channels
core show callsShow active call count
voicemail show usersList voicemail boxes
core reloadReload configuration
core restart gracefullyRestart after active calls end
dialplan showDisplay dialplan contexts
rtp set debug onEnable RTP debugging

SIP Tools

sngrepInteractive SIP flow viewer
sngrep -rShow RTP stream analysis
sngrep -cCapture mode
heplify -hsHEP capture for Homer

Wireshark Filters

sipAll SIP protocol traffic
rtp || rtcpMedia streams and control
sip.Method == "INVITE"Call setup messages only
sip.Status-Code == 200Successful responses
ip.addr == 192.168.10.100Specific host traffic
udp.port == 5060SIP on standard port
frame contains "REGISTER"Search packet payload

SNMP

snmpwalk -v2c -c public IPWalk MIB tree (v2c)
snmpwalk -v3 -u user -l authPrivWalk with SNMPv3
show snmp communityShow SNMP communities (IOS)
show snmp userShow SNMPv3 users (IOS)