VoIP Infrastructure & SIP Communications Platform

When I first set out to build this project, it was more than just learning how VoIP worked or how to configure softphones and IP phones — this project had a real-world purpose.

After moving into my current residence, I quickly discovered that mobile signal coverage was extremely poor, making reliable 4G and 5G voice calls nearly impossible. Rather than relying on external solutions, I decided to build my own self-hosted VoIP platform as part of my growing homelab infrastructure.

At the time, this became more than just a project; it marked the beginning of my self-hosted infrastructure journey and laid the foundation for everything that followed within my home lab environment.

Project Goals

From the beginning, I set several requirements for the system:

• Keep operational costs below £5 per month
• Support both softphones and physical IP phones
• Maintain reliable uptime and service stability
• Integrate with Windows Active Directory where possible
• Run on Linux or another open-source operating system

Before deploying the environment, I spent significant time researching and learning the fundamentals required to properly understand and troubleshoot VoIP infrastructure, including:

• How VoIP communications function
• SIP protocol architecture and call handling
• Different VoIP platforms and their suitability for small-scale deployments
• Device provisioning and network requirements for IP telephony

After several weeks of research and testing, I selected FreePBX as the core platform due to its open-source nature, flexibility, feature set, and the opportunity it provided to deepen my technical knowledge.

Initial Environment

The original deployment consisted of:

• FreePBX hosted within a virtual machine
• MicroSIP softphone for Windows
• MizuDroid softphone for Android

Initially, the goal was simply to establish stable SIP communication between devices across the local network. After successfully configuring inbound and outbound calling between the softphones, I began expanding the environment to include dedicated physical IP phones.

Physical IP Phone Integration

To extend the platform further, I introduced a Cisco 7911 IP phone into the environment, allowing for a permanently connected desk phone capable of handling inbound and outbound calls.

One of the major learning experiences during this stage was discovering that the Cisco 7911 did not provide a traditional web management interface. Instead, all provisioning and configuration had to be handled manually through XML configuration files delivered via TFTP.

Although initially challenging, this significantly improved my understanding of:

• Phone provisioning
• TFTP deployment
• SIP registration behaviour
• Dial plans and call routing
• Device-level customisation and configuration management

Through this process, I was able to customise nearly every aspect of the phone, including:

• Dial plans
• Firmware behaviour
• Idle screen images
• Ringtones and interface settings

Troubleshooting & Reliability Improvements

After running the environment for several weeks, I began experiencing intermittent reliability issues with the Cisco handset. Inbound calls would occasionally fail to ring, and outbound calls would sometimes disconnect unexpectedly.

Interestingly, these issues did not occur when using MicroSIP, which indicated that the problem was likely isolated to the physical handset configuration rather than the VoIP server itself.

To troubleshoot the issue, I performed extensive testing, including:

• Reviewing and modifying phone configuration files
• Testing different network cables and switch ports
• Monitoring SIP registration behaviour
• Comparing softphone and hardware phone performance

To further isolate the issue, I obtained a Mitel 5224 IP phone, which provided a more modern web-based management interface for comparison testing.

After comparing both devices and reviewing the Cisco configuration in detail, I identified that a critical keepalive and registration refresh setting had been omitted from the original configuration. This prevented the phone from periodically refreshing its configuration and SIP registration state with the TFTP and VoIP servers.

Once corrected, the platform became significantly more stable and reliable.

Outcome

This project provided hands-on experience with real-world VoIP deployment, SIP communications, device provisioning, and network troubleshooting within a self-hosted infrastructure environment.

More importantly, it established the foundation of my wider homelab ecosystem and significantly strengthened my understanding of:

• Linux-based infrastructure
• Network communications
• SIP and VoIP technologies
• Troubleshooting methodologies
• Service reliability and uptime management
• Infrastructure planning and deployment

This project ultimately became the first major service within my enterprise-style homelab platform and sparked my continued interest in networking, infrastructure, and self-hosted services.