VoIP (Voice over Internet Protocol) works by converting analog voice signals into digital data packets, transmitting them over an IP network using signaling protocols like SIP for call setup and RTP for media transport, then reassembling and decoding them back into audio at the receiver. VideoSDK leverages the same packet-switched principles through its real-time communication SDKs, enabling developers to embed voice and video calling without managing the underlying transport layer. To dive deeper into building voice applications, explore the VideoSDK audio calling guide.
For over a century, phone calls traveled through dedicated copper wires and circuit-switched exchanges managed by telecom monopolies. That model worked, but it was expensive, rigid, and built for voice alone. Today, most voice traffic moves across the same internet infrastructure that carries your web requests, video streams, and chat messages.
The shift from circuit-switched Public Switched Telephone Network (PSTN) lines to packet-switched IP networks changed how every phone call is routed, billed, and engineered. If you are building communication features into an application, understanding the mechanics of VoIP gives you control over call quality, latency, security, and cost. By the end of this article, you will understand the full VoIP call flow from audio capture to playback, the protocol stack that makes it possible, and the network requirements that separate a crisp call from a garbled one.
What is VoIP?
VoIP is defined as a technology that enables voice communication and multimedia sessions over internet protocol (IP) networks rather than traditional circuit-switched telephone lines. Instead of dedicating a continuous copper circuit between two callers for the duration of a call, VoIP breaks voice into small digital packets that travel independently across the network and are reassembled at the destination.
VoIP works by performing three core operations in rapid succession: digitizing analog audio through a codec, signaling the call setup and teardown through a protocol like SIP, and transporting the encoded audio packets using RTP over UDP. The receiving endpoint reverses the process, decoding packets back into audible sound.
This architecture matters because it treats voice as just another type of data. That means voice calls can leverage the same scalability, redundancy, and cost structure as any internet application. For developers, this opens the door to building voice features directly into web and mobile apps using SDKs like VideoSDK's audio calling capabilities, which abstract away the protocol complexity while preserving the underlying packet-switched efficiency.
Core Components of a VoIP Call
Every VoIP call, regardless of the hardware or software involved, passes through four fundamental stages. Understanding each stage helps you diagnose call quality issues and choose the right configuration for your deployment.
1. Audio Capture and Digitization
The call begins at a microphone or handset. The microphone captures analog sound waves and converts them into electrical signals. An Analog-to-Digital Converter (ADC) then samples these signals at a specific rate, typically 8,000 or 16,000 or 48,000 times per second depending on the codec. Each sample is quantized into a digital value. A codec then compresses this raw digital audio to reduce bandwidth consumption while preserving intelligibility. The choice of codec directly affects both call quality and the network resources the call consumes.
2. Signaling with SIP
Before any voice packets flow, the two endpoints need to agree that a call is happening. The Session Initiation Protocol (SIP) handles this negotiation. SIP is a text-based application-layer protocol defined in IETF RFC 3261 that manages call setup, ringing, answer, and teardown. When you dial a number, your VoIP client sends a SIP INVITE message to the receiving party through a SIP server or proxy. The receiver responds with a 200 OK, and the caller confirms with a SIP ACK. This three-way handshake establishes the session parameters before media flows.
3. Media Transport with RTP
Once the SIP session is established, the actual voice data moves over the Real-time Transport Protocol (RTP), defined in IETF RFC 3550. RTP packets carry the encoded audio payload along with sequencing numbers and timestamps that allow the receiver to reorder packets and manage timing. RTP runs over UDP rather than TCP because real-time audio cannot tolerate the retransmission delays that TCP's reliability mechanisms introduce. If a voice packet is lost, the receiver interpolates or plays silence rather than waiting for a retransmission that would arrive too late to matter.
4. Decoding and Playback
At the receiving endpoint, the process reverses. The jitter buffer collects incoming RTP packets and holds them briefly to smooth out arrival timing variations. The decoder then decompresses the audio data using the same codec that encoded it. A Digital-to-Analog Converter (DAC) converts the digital samples back into analog electrical signals, which the speaker plays as audible sound. The entire round trip, from microphone to speaker, typically completes in under 150 milliseconds for a high-quality call.
Step-by-Step Call Flow
To understand how VoIP works end to end, let us walk through a complete call from the moment a user picks up a phone to the moment they hang up. This narrative covers both the signaling path and the media path, which often travel through different servers.
When a user picks up a VoIP phone and dials a number, the phone first registers with its SIP registrar server to announce its availability and location. The dialing action triggers a SIP INVITE message containing the caller's media capabilities, preferred codecs, and IP address for receiving RTP streams. The SIP proxy server receives this INVITE and routes it toward the destination, potentially traversing multiple proxy hops or a SIP trunk to reach the called party.
The destination phone receives the INVITE and alerts the user by ringing. It responds with a SIP 180 Ringing message that travels back through the proxy chain to the caller, confirming that the call is reaching the destination. When the called party answers, their phone sends a 200 OK response containing its own media description, including the codec it selected from the caller's offered list and its RTP receiving address. The caller's phone acknowledges with a SIP ACK, and the session is now fully established.
At this point, media flows in both directions. Each phone encodes audio from its microphone using the negotiated codec, packetizes the encoded data into RTP packets, and sends them over UDP to the other party's IP address and port. The RTP Control Protocol (RTCP) runs alongside RTP, providing periodic feedback on packet loss, jitter, and round-trip time so endpoints can adapt to network conditions.
When either party hangs up, their phone sends a SIP BYE message. The other party confirms with a 200 OK, and the session terminates. Any associated resources, including ports, codec instances, and jitter buffers, are released.
VoIP Protocol Stack
VoIP does not rely on a single protocol. It stacks multiple protocols across the OSI model, each handling a specific responsibility. Understanding this stack helps you troubleshoot issues at the correct layer and choose the right security mechanisms.
At the bottom, the network layer uses IP to route packets between endpoints. The transport layer uses UDP for RTP media traffic because it avoids the head-of-line blocking and retransmission delays of TCP. SIP signaling, however, can run over UDP, TCP, or TLS depending on the deployment's security requirements.
The Session Description Protocol (SDP) works alongside SIP to describe the media parameters of the session. SDP is not a transport protocol but a format for specifying codecs, port numbers, payload types, and other media attributes. When a SIP INVITE carries an SDP body, it tells the receiver exactly how to decode the incoming RTP stream.
For security, VoIP deployments can add TLS to encrypt SIP signaling, protecting call setup metadata from eavesdropping. For media encryption, the Secure Real-time Transport Protocol (SRTP) encrypts the RTP payload while preserving the header structure needed for packet routing and timing. Many modern VoIP systems mandate SRTP to prevent packet capture and replay attacks.
VideoSDK's real-time communication infrastructure handles this entire protocol stack for you. When you use the VideoSDK REST APIs to create rooms and manage participants, the SDK manages signaling, media transport, encryption, and codec negotiation under the hood.
Common VoIP Codecs and Their Trade-offs
The codec you choose for a VoIP call determines the balance between audio quality, bandwidth consumption, and computational cost. Different codecs are optimized for different scenarios, and most VoIP systems support multiple codecs with negotiation during call setup.
G.711 is the simplest and most widely supported codec. It uses uncompressed pulse code modulation at 64 kbps, delivering toll-quality voice with minimal processing. However, it consumes significant bandwidth and is sensitive to packet loss because it has no built-in redundancy or compression.
G.729 compresses voice to 8 kbps using a conjugate-structure algebraic code-excited linear prediction algorithm. It was popular in bandwidth-constrained environments but requires licensing, which limited its adoption in open-source projects. G.729a is a lower-complexity variant that reduces CPU usage at the cost of slight quality degradation.
Opus is the modern standard for real-time voice and audio over IP. It is royalty-free, standardized by the IETF in RFC 6716, and supports bitrates from 6 kbps to 510 kbps. Opus dynamically adjusts its bitrate and complexity based on network conditions, making it ideal for variable-quality networks like mobile data connections. Most contemporary WebRTC implementations, including VideoSDK's SDKs, use Opus as their default audio codec.
AAC-LD (Advanced Audio Coding with Low Delay) is used in some video conferencing systems for its ability to handle both voice and music at low latency. It operates at bitrates from 16 to 64 kbps and offers good quality for mixed audio content, though it is less common in pure voice telephony than Opus or G.711.
| Codec | Bitrate | Quality | Latency | Best For |
|---|---|---|---|---|
| G.711 | 64 kbps | Toll quality | Low | Legacy compatibility, high-bandwidth networks |
| G.729 | 8 kbps | Good | Medium | Bandwidth-constrained links |
| Opus | 6 to 510 kbps | Excellent | Very low | Modern WebRTC, adaptive networks |
| AAC-LD | 16 to 64 kbps | Good for mixed audio | Low | Video conferencing with music |
[LINKABLE ASSET: codec comparison table]
Opus stands out because it adapts in real time. When network conditions degrade, Opus reduces its bitrate to maintain call continuity rather than dropping packets entirely. This is the same adaptive principle that VideoSDK applies through its network-adaptive streaming feature, which automatically adjusts bitrate and resolution based on real-time bandwidth detection.
Network Requirements for Good Call Quality
VoIP call quality depends heavily on network conditions. Three metrics matter most: latency, jitter, and packet loss. Understanding their thresholds helps you design networks and choose providers that deliver reliable voice.
Latency is the time it takes for a voice packet to travel from sender to receiver. For one-way voice, latency below 150 milliseconds is generally imperceptible to users. Between 150 and 300 milliseconds, callers notice a walkie-talkie effect where they accidentally talk over each other. Above 300 milliseconds, conversation becomes difficult and unnatural.
Jitter is the variation in packet arrival times. Even if average latency is low, high jitter causes packets to arrive out of order or in bursts. VoIP endpoints use jitter buffers to absorb this variation by holding packets briefly before playback. A jitter buffer of 20 to 50 milliseconds handles most network conditions, but larger buffers increase overall latency. If jitter exceeds the buffer depth, packets are discarded, creating audible gaps.
Packet loss occurs when packets are dropped due to network congestion, routing errors, or wireless interference. Loss rates below 1 percent are generally inaudible with modern codecs that include packet loss concealment. Between 1 and 3 percent, callers hear occasional clicks or gaps. Above 3 percent, calls become choppy and difficult to understand.
Quality of Service (QoS) configurations help prioritize voice traffic over less time-sensitive data. By marking RTP packets with a higher DSCP (Differentiated Services Code Point) value, routers and switches can prioritize voice queues over bulk data transfers. Without QoS, a large file download on the same network can saturate the link and degrade call quality.
Bandwidth requirements depend on the codec and the number of simultaneous calls. A single G.711 call consumes about 87 kbps in each direction including IP overhead, while an Opus call at 24 kbps consumes roughly 40 kbps with overhead. For deployments with many concurrent calls, multiply per-call bandwidth by the expected number of simultaneous sessions and add a 20 percent overhead buffer for signaling and control traffic.
Security Considerations
VoIP systems face several security threats that traditional PSTN calls did not encounter. Because voice packets travel over the same networks as general internet traffic, they are exposed to interception, injection, and denial-of-service attacks.
Encryption is the first line of defense. TLS should protect SIP signaling to prevent attackers from reading call metadata, forging INVITE messages, or hijacking sessions. SRTP should encrypt the RTP media stream to protect the actual voice content. Many enterprise VoIP deployments now mandate both layers.
Firewalls and Session Border Controllers (SBCs) protect VoIP infrastructure from unauthorized access. SBCs sit at the network edge and inspect SIP and RTP traffic, enforcing authentication, preventing IP spoofing, and managing NAT traversal. They also rate-limit registration attempts to block brute-force attacks against SIP credentials.
VPN tunnels can secure VoIP traffic between remote offices and the central PBX, especially when calls traverse untrusted networks like public Wi-Fi. However, VPNs add encryption overhead and latency, so they should be tested before deployment in latency-sensitive environments.
Authentication is critical. SIP endpoints should always authenticate with the registrar using digest authentication, and SIP trunks should use mutual TLS where the provider supports it. Weak or default passwords on VoIP phones are a common entry point for toll fraud, where attackers make expensive international calls at the organization's expense.
For developers building voice applications with VideoSDK, the platform includes E2E encryption and token-based authentication that addresses these concerns at the SDK level. You can learn more about secure token generation in the VideoSDK authentication guide.
VoIP vs. Traditional PSTN
The architectural difference between VoIP and PSTN is fundamental. PSTN uses circuit switching, where a dedicated physical path is established between caller and receiver for the entire duration of the call. That path reserves bandwidth whether anyone is speaking or not. VoIP uses packet switching, where voice data shares network resources with all other traffic and packets take independent routes to the destination.
This difference has practical consequences. PSTN calls are highly reliable for voice because the dedicated circuit guarantees bandwidth, but they are expensive to scale because each call consumes a physical resource. VoIP calls are cheaper because they share infrastructure with data traffic, but they require careful network engineering to maintain quality.
PSTN offers limited features beyond voice: call waiting, caller ID, and three-way calling are about the extent of it. VoIP enables rich features like video calling, screen sharing, real-time transcription, interactive live streaming, and AI-powered voice agents because voice is just another data stream that applications can process.
Cost structures also differ dramatically. PSTN lines require per-line monthly rentals and per-minute long-distance charges. VoIP calls over the internet cost effectively nothing per minute, and SIP trunking replaces physical lines with virtual trunks that can scale on demand.
For organizations transitioning from PSTN to VoIP, VideoSDK's telephony and SIP integration bridges the gap by connecting traditional SIP trunk providers like Twilio, Vonage, and Telnyx to WebRTC-based rooms, enabling a smooth migration path.
Practical Tips for Deploying VoIP
Deploying VoIP in production requires more than plugging in phones. The following considerations separate a reliable deployment from one plagued by quality complaints.
Choose the Right Hardware
IP phones should support your chosen codecs, particularly Opus for modern deployments. Analog Telephone Adapters (ATAs) let you connect legacy analog phones to a VoIP network by digitizing their audio and handling SIP registration. For headsets and softphones, choose devices with good acoustic echo cancellation and noise suppression. VideoSDK's SDKs include built-in noise suppression, which reduces the hardware requirements for acceptable call quality.
Configure SIP Trunks Properly
SIP trunking replaces traditional phone lines with a virtual connection to your VoIP provider. When configuring SIP trunks, verify that your provider supports the codecs you need, configure inbound and outbound routing rules, and test DTMF (touch-tone) signaling for IVR systems. Ensure your firewall allows RTP traffic on the port range your provider specifies, and configure NAT keep-alives to prevent sessions from timing out.
Test Bandwidth Before Deployment
Before rolling out VoIP to users, run bandwidth tests on the production network during peak hours. Measure not just throughput but also latency, jitter, and packet loss to the SIP provider's servers. Tools that generate synthetic RTP traffic can simulate call conditions without requiring actual calls. If the network cannot sustain the expected number of concurrent calls with headroom, upgrade the connection or implement QoS before deployment.
Monitor Quality of Service Continuously
VoIP quality is not a set-and-forget configuration. Monitor RTCP reports from your endpoints to track packet loss, jitter, and round-trip time in real time. Set up alerts for calls that exceed quality thresholds so you can investigate network issues before users complain. VideoSDK provides session analytics through its REST API that expose call quality metrics for monitoring and alerting.
Definitions Glossary
VoIP (Voice over Internet Protocol): A technology that transmits voice communication over IP networks by converting analog audio into digital packets. VideoSDK's audio calling SDKs use the same packet-switched principles to deliver real-time voice in web and mobile apps.
SIP (Session Initiation Protocol): An application-layer signaling protocol that manages VoIP call setup, modification, and teardown. SIP handles INVITE, 200 OK, ACK, and BYE messages that establish and terminate communication sessions.
RTP (Real-time Transport Protocol): A network protocol that carries encoded audio and video packets over UDP. RTP includes sequencing and timestamping so receivers can reorder packets and manage playback timing.
Codec: A software algorithm that compresses and decompresses digital audio. VoIP codecs like Opus and G.711 determine the trade-off between call quality and bandwidth consumption.
Jitter Buffer: A temporary buffer on the receiving endpoint that holds incoming RTP packets to smooth out arrival time variations before playback. Larger buffers reduce jitter artifacts but increase overall latency.
SIP Trunking: A method of delivering telephone services over the internet by connecting a PBX to a VoIP provider through SIP. VideoSDK's telephony integration bridges SIP trunks from providers like Twilio and Telnyx to WebRTC rooms.
SRTP (Secure Real-time Transport Protocol): An extension of RTP that encrypts the media payload to protect voice content from interception while preserving the RTP header structure needed for routing and timing.
Key Takeaways
- VoIP works by digitizing analog voice, signaling the call with SIP, transporting media with RTP over UDP, and decoding packets back into audio at the receiver.
- The choice of codec directly impacts call quality and bandwidth consumption, with Opus being the modern standard for adaptive real-time voice.
- Network quality metrics, specifically latency below 150 milliseconds, jitter under 30 milliseconds, and packet loss below 1 percent, define the difference between a clear call and an unusable one.
- Security layers including TLS for SIP signaling and SRTP for media encryption are essential for protecting VoIP traffic on shared IP networks.
- VideoSDK abstracts the entire VoIP protocol stack, including signaling, media transport, codec negotiation, and encryption, letting developers embed real-time voice and video calling without managing the underlying infrastructure.
Conclusion
Understanding how VoIP works gives you the foundation to build, debug, and scale real-time voice applications. From the moment a microphone captures analog sound to the moment a speaker plays it back on the other end, a coordinated stack of protocols, codecs, and network mechanisms works together to deliver conversation-quality audio over packet-switched networks. Whether you are deploying a SIP trunk for an enterprise phone system or embedding voice calling into a mobile app, the principles of signaling, media transport, and quality management remain the same. VideoSDK handles this complexity at the SDK level, so you can focus on your application logic rather than protocol negotiation and jitter buffer tuning. Ready to build? Start with the VideoSDK quickstart guide or sign up at app.videosdk.live/login to get your free credits. What are you building with VoIP? Drop a comment, I would love to hear what kind of voice communication use case you are working on.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ