VoIP (Voice over IP) refers to making voice (and video) calls over an IP network, like the Internet, rather than over a traditional telephone line. Rather than being a single protocol, VoIP relies on two protocols working together: SIP, which handles setting up, managing, and ending a call, and RTP, which actually carries the voice or video data once the call is underway.
SIP (Session Initiation Protocol)
SIP is a signalling protocol — its job is to establish, modify, and terminate a communication session between two or more participants. Crucially, SIP itself never carries the actual voice or video content of a call; it’s purely responsible for the setup and teardown process, similar in spirit to how a phone system’s dial tone, ringing, and call routing are logically separate from the actual conversation itself.
SIP typically operates on port 5060 (unencrypted) or port 5061 (encrypted, via TLS).
SIP messages
SIP uses a text-based request/response format, deliberately designed to look somewhat familiar to anyone who already understands HTTP (see the HTTP & HTTPS page) — both share a broadly similar request-line, header, and body structure.
Common SIP request types (called “methods”, again mirroring HTTP terminology) include:
- INVITE: Initiates a call, requesting that a session be established with another party.
- ACK: Confirms that a final response to an INVITE has been received, completing the handshake.
- BYE: Terminates an existing call.
- CANCEL: Cancels a call that hasn’t yet been answered.
- REGISTER: Used by a SIP device (a desk phone, or a softphone application) to tell a SIP server where it can currently be reached, similar in concept to how a mobile phone registers with the nearest cell tower.
A basic call setup
A simplified version of what happens when one SIP device calls another:
- The caller’s device sends an INVITE message toward the callee, describing the type of session being requested (audio, video) and proposing details about how the actual media should be sent (which codecs are supported, which network address and port to use — this description uses a companion format called SDP, the Session Description Protocol).
- The callee’s device (or phone system) responds with a series of provisional responses, such as 180 Ringing, letting the caller know the call is being attempted.
- If the callee answers, a 200 OK response is sent back, confirming the session and including the callee’s own media details.
- The caller sends an ACK, completing the three-way handshake and confirming the session is now fully established.
- At this point, SIP’s job for call setup is complete, and the actual voice data begins flowing directly between the two devices using RTP (see below) — not through SIP itself.
- When either party hangs up, a BYE message is sent, ending the session.
H.323
H.323 is an older signalling protocol suite, standardised by the ITU-T (the same standards body responsible for many traditional telecoms standards) rather than the IETF, which developed SIP. H.323 predates SIP by a few years and was originally designed for video conferencing over local networks, later expanding to cover VoIP more broadly. Where SIP is a single, relatively lightweight text-based protocol, H.323 is better described as an entire suite of related protocols and components working together.
Key components
- H.225: Handles call signalling and setup — broadly comparable to the role SIP itself plays, but using a binary rather than text-based message format.
- H.245: Handles capability negotiation once a call is being set up — agreeing on which audio/video codecs both ends support, similar to the role SDP plays alongside SIP.
- Gatekeeper: An optional but commonly used component that manages address translation, admission control, and bandwidth management for a group of H.323 devices — conceptually similar to a SIP registrar/proxy server, though H.323 gives this role a more clearly defined, mandatory-feeling place in the architecture.
- Gateway: Bridges an H.323 network to other types of network — most commonly the traditional telephone network (the PSTN), allowing an H.323 VoIP call to be connected through to an ordinary landline or mobile number.
- MCU (Multipoint Control Unit): Manages conference calls involving more than two participants, mixing and distributing audio/video streams between everyone on the call.
H.323 vs SIP
H.323 and SIP solve broadly the same problem — signalling and setting up a real-time voice/video session — but took quite different design approaches, and this is a large part of why SIP has become the dominant standard for new VoIP deployments:
| H.323 | SIP | |
|---|---|---|
| Message format | Binary | Text-based |
| Standards body | ITU-T | IETF |
| Design style | Tightly defined, telecoms-oriented | Loosely coupled, Internet-oriented (closer in spirit to HTTP) |
| Extensibility | More rigid | Easier to extend with new features |
| Common today | Legacy video conferencing, some carrier networks | The de facto standard for modern VoIP |
Despite SIP’s dominance in newer deployments, H.323 hasn’t disappeared entirely — it remains in use in some legacy enterprise video conferencing systems and within parts of carrier/telecoms infrastructure that adopted it early and have had less reason to migrate away.
Notably, whatever signalling protocol is used to set the call up — H.323 or SIP — the actual audio/video data itself is still typically carried using RTP, described below. This is a useful way to remember the overall shape of a VoIP call: the signalling layer (H.323 or SIP) decides that a call should happen and agrees on the details, while RTP is what actually carries it once that agreement is in place.
RTP (Real-time Transport Protocol)
Once SIP has finished negotiating and establishing a session, RTP takes over as the protocol actually responsible for carrying the real-time voice (or video) data between the two parties for the duration of the call.
RTP runs over UDP rather than TCP — a deliberate choice, for much the same reason covered on the QUIC page: voice and video are time-sensitive, and a brief, occasional missing or corrupted chunk of audio is generally far less disruptive to a phone call than the delay TCP’s retransmission and strict ordering guarantees would introduce while waiting for that missing chunk to be resent. A short audio glitch is a much better outcome for a live conversation than a noticeable pause.
Each RTP packet includes a sequence number (allowing the receiving end to detect if packets have arrived out of order, or gone missing entirely) and a timestamp (allowing the receiving end to play the audio back at the correct pace, smoothing out any small variations in exactly when packets happened to arrive over the network).
Codecs
RTP itself doesn’t dictate how audio or video is actually encoded — that’s the job of a codec, negotiated during the SIP call setup described above. Common voice codecs include G.711 (higher audio quality, but uses more bandwidth) and G.729 (more compressed, using less bandwidth at some cost to quality) — the choice made during setup is a direct trade-off between call quality and how much network bandwidth the call consumes.
VoIP protocols and security
VoIP inherits many of the same security considerations already covered elsewhere on this site, plus a few specific to real-time voice communication.
Unencrypted SIP and RTP can be intercepted and eavesdropped. By default, both SIP signalling and RTP media can be sent entirely unencrypted, meaning anyone in a position to intercept the traffic — the same kind of position covered on the Man in the Middle page — could potentially both see who is calling whom (from SIP) and reconstruct the actual audio of the conversation itself (from RTP). SIPS (SIP over TLS, using port 5061) and SRTP (Secure RTP, which adds encryption and authentication to the media stream) exist specifically to close this gap, and should be treated as a baseline requirement for any VoIP deployment handling sensitive conversations.
Toll fraud is a VoIP-specific financial risk. If an attacker gains unauthorised access to a business’s VoIP system — often via a weakly-secured SIP trunk or a compromised set of SIP registration credentials — they can route large volumes of expensive international or premium-rate calls through the victim’s system, leaving the victim organisation to foot a substantial, entirely fraudulent phone bill, sometimes running into tens of thousands of pounds before it’s noticed.
SIP flooding / VoIP Denial of Service attacks work in a similar way to other flooding-based Denial of Service techniques covered on the Denial of Service (DoS) page — an attacker overwhelms a SIP server with a large volume of INVITE or REGISTER requests, exhausting its resources and preventing legitimate calls from being set up at all.
Vishing (voice phishing) is the voice-call equivalent of the techniques already covered on the Phishing page, and VoIP is directly what makes it so easy and cheap to carry out at scale. Because VoIP systems typically allow the caller ID presented to the recipient to be freely set by whoever is placing the call, an attacker can cheaply and convincingly spoof caller ID, making a fraudulent call appear to come from a trusted number — a bank’s real customer service line, or even a colleague’s genuine internal extension — as a way of building false trust before attempting to extract sensitive information or credentials over the phone.
Given these risks, VoIP deployments handling anything sensitive should generally enforce SIPS/SRTP rather than plain SIP/RTP, apply the same kind of access restrictions and monitoring recommended for RDP and SMB elsewhere on this site, and treat an unexpected or unusual pattern of outbound international calling as a potential sign of toll fraud worth investigating promptly.