Voice over IP turns a conversation into short pieces of digital audio and carries them across an IP network. A calling service finds the destination and manages features such as ringing and voicemail; the endpoints exchange audio along a media path. Following those two jobs makes both the technology and its common failures easier to understand.
This explanation uses a typical SIP-based voice call. Apps can use other signaling systems, and a provider may relay or process the audio. The same practical questions still apply: who controls the call, where does the sound travel, and what equipment must keep working?
The parts between two voices
An endpoint is the device that captures and plays sound: a desk phone, a softphone app with a headset, or an analog phone connected through an analog telephone adapter (ATA). A codec encodes the microphone signal and decodes received audio. The access network carries packets through Ethernet or Wi-Fi, a router, and the relevant internet or private-network connection.
A PBX, or private branch exchange, supplies an organization’s calling functions. It can run on premises or be hosted by a provider. A public telephone number also needs service that reaches the public switched telephone network (PSTN). Installing a calling app and obtaining that telephone service are separate decisions.
Signaling: arrange the conversation
SIP requests and responses establish, change and end sessions. A registration can tell the service where an account is reachable. SIP messages can carry an SDP description of proposed media parameters. See the SIP specification and SDP specification.
Media: carry the conversation
RTP carries real-time media with sequence numbers and timestamps that help receivers handle arrival order and playback timing. RTCP supplies related control and reception reports. A successful call setup and a working audio path therefore require separate checks. See RTP and RTCP.
Follow a call from dialing to listening
Imagine Maya calls a colleague using two supported SIP phones. This is a simplified, successful exchange; authentication challenges, additional proxies and early media are omitted.
- Prepare the endpoint. The phone obtains network connectivity and the configuration needed for its service. Where registration is used, the account registers. A “registered” indicator is useful evidence of this stage.
- Request the call. The caller sends a SIP INVITE toward the destination through the calling service. An SDP offer can describe supported audio formats and where media should be sent.
- Ring and answer. A typical flow includes a 180 Ringing response, then a 200 OK when the call is accepted. The caller sends ACK. The offer and answer establish compatible media parameters.
- Send audio in both directions. Each endpoint encodes microphone audio into packets. Media may travel directly or through provider infrastructure; its route can differ from the signaling route.
- Reconstruct speech. The receiver briefly buffers arriving packets, decodes them and sends sound to the speaker. Buffering accommodates uneven arrival but adds delay; missing or late audio may require concealment.
- End the session. In this established SIP call, either party can send BYE, which the other acknowledges with a successful response.
The message sequence is based on SIP’s overview of operation. The caller’s screen can say “connected” after signaling succeeds while one direction of media still fails. That is why a useful acceptance test includes a conversation in both directions.
If the destination is a conventional telephone number, the service routes the call into the appropriate telephone network. That journey may involve gateways, carrier interconnections and transcoding between audio formats. The two phones do not need identical physical connections to complete a call.
A packet is larger than its audio payload
Worked example: one G.711 stream
Assume continuous G.711 audio at 64,000 bits per second, 20 ms of audio per packet, and ordinary IPv4/UDP/RTP headers totaling 40 bytes. This deliberately simplified example excludes link-layer overhead, encryption overhead, header extensions, tunnels, signaling and RTCP.
- Packets each second: 1 ÷ 0.020 = 50.
- Audio payload: 64,000 × 0.020 ÷ 8 = 160 bytes.
- IP packet size: 160 + 40 = 200 bytes.
- Rate in one direction: 200 × 8 × 50 = 80,000 bits/s, or 80 kbit/s.
For ten simultaneous calls crossing the same access link, with one such stream per call in each direction, the audio IP packets total 800 kbit/s upstream and 800 kbit/s downstream. Each direction needs that capacity; combining them into one number hides an upload bottleneck.
The codec and header assumptions follow Cisco’s voice bandwidth calculation guide. Actual provisioning must include the omitted overhead, other traffic and operating headroom. A speed-test result alone cannot establish call quality under load. Different codecs, packet intervals, silence handling and media paths change the calculation.
Longer packet intervals reduce the number of headers sent per second, but collect more audio before transmission and put more speech at risk when a packet is lost. Treat packetization as an endpoint and service design choice, with supported settings and a measured outcome.
Use the symptom to choose the next check
| What happens | What it suggests checking | Useful evidence |
|---|---|---|
| Phone stays offline | Power, network access, account and provisioning | Device status, firmware, registration error and service status |
| One destination will not connect | Dialed format, permissions and routing for that destination | Timestamp, call identifier and response or failure code |
| Call connects; one person hears silence | Mute and selected audio devices, then the media path in each direction | Who hears whom, endpoint meters and directional media statistics |
| Speech breaks up | Audio processing and packet delivery under the affected conditions | Loss and jitter over time, device load and a comparable wired test |
| Conversation has a long pause | End-to-end delay and buffering along the actual media path | Defined latency metric and measurement points |
On a narrow screen, focus the table and scroll horizontally.
Change one variable, repeat an ordinary test call, and record the outcome. A local recording can check a microphone; an external two-way call checks a much larger path. The call-quality measurement guide explains how to separate those observations.
What the explanation means when choosing service
Check the supported phone or app, the calling service, the network, and the power arrangements together. For security, ask which signaling and media segments are protected and where calls are decrypted or recorded. SRTP defines protection for real-time media; the implementation and its trust boundaries determine the protection a particular call receives.
For a purchase or migration, continue with choosing and testing VoIP phones, planning business VoIP, or moving a household phone service. For broader context, read how VoIP changed telecom.