What Is RTP, and Why Does the Voice Travel Separately from SIP?

Definition and origin

RTP stands for Real-time Transport Protocol. It was first standardized in the mid-1990s, and the version in use today is defined in the RFC 3550 standard. It is used not only for phone calls, but also for video and live broadcasts.

The idea is simple: the voice is cut into short slices, usually 20 milliseconds each, and each slice is sent in a separate packet. That is about 50 packets per second in each direction. Each packet is stamped with a sequence number and a timestamp, so the other side knows how to put them in order and play them at the right pace.

A simple picture: a film arriving by mail, one frame in each envelope. If every envelope is numbered, you can put them in order even if they arrive jumbled, and know which one is missing.

Two channels in one call

Every VoIP call has two separate channels, and it is worth knowing both:

Because of these differences, each channel behaves differently on the network. So the phone can ring and be answered, meaning SIP worked, and still nothing is heard, because RTP was blocked on the way.

Why separate them at all?

The question is: why not send everything in one channel? There are three main reasons.

• Different requirements: a control message must arrive complete, even if late. Voice must arrive on time, even if a small slice is missing. One protocol cannot do both well.
• A different route: the control messages go through the PBX server, but the voice can take another route, and in some cases even go directly between the two phones. This saves delay.
• Flexibility: in the middle of a call you can switch the voice channel without hanging up: transfer the call, put it on hold with music, or connect it to a conference. The control channel stays, and the voice channel is "rewired".

The picture: on a flight, the control tower talks to the pilot by radio, while the passengers themselves board the plane. The radio manages the flight, and the plane carries what really matters. Nobody would send the passengers through the radio.

How the voice channel is set up

At the start of the call, inside the SIP messages, each side writes a small "business card" in a format called SDP. The card says which address and which port to send the voice to, and which codecs it can use.

1. The calling phone sends: "Send me voice at my address, port 12000. I know G.722 and G.711."
2. The other side answers: "I will send to you in G.711. And you send to me at this address, port 30400."
3. Both sides start sending RTP to each other, each to the address the other asked for.

This is the weak point. If the phone sits behind a router, the address it writes on the card is a private address, which means nothing outside. Good telephony servers handle this and send the voice to the address the packets actually come from. For more on this whole subject, see NAT.

What happens to a packet on the way

An RTP packet leaves the phone, passes through the switch, the router, the internet provider and the networks along the way, and reaches the server. At each such link, three things can happen, and each sounds different:

• Latency: the packet arrives, but late. You feel a "delay", and people talk over each other. A one-way latency of up to about 150 milliseconds is considered good, according to the ITU-T G.114 recommendation.
• Jitter: the packets arrive at an uneven pace. The phone keeps a small "buffer" to even out the pace, and when the jitter is too large, the voice sounds choppy or robotic.
• Packet loss: some of the packets do not arrive at all. You hear gaps, swallowed words, a "stuttering" voice.

A fuller explanation of the first two is in Latency and Jitter, and of the third in Packet Loss. What matters to remember here: RTP does not fix these problems. It only lets the other side detect them and hide them as much as possible.

RTCP and SRTP, the two siblings

RTP has two "relatives" that are worth knowing by name:

• RTCP (RTP Control Protocol): a small channel that runs alongside the voice and sends a report every few seconds: how many packets were received, how many were lost, what the jitter was. Quality scores such as MOS are calculated from it. It does not carry voice.
• SRTP (Secure RTP): encrypted RTP. The packets travel the same way, but anyone intercepting them on the way cannot understand what was said. See Encryption.

In many systems you can see, at the end of the call, a summary built from RTCP data. It is a very useful diagnostic tool when a user complains that "it was bad", and there is no way to tell whether the problem was on his side, on the internet, or on the other end.

How much bandwidth RTP uses

Every RTP packet carries a little voice and a lot of "envelope": RTP, UDP and IP headers, plus headers from the local network. In packets this small, the envelope is a large part of the weight. So the actual usage is higher than the codec's own rate.

The usage is per call and per direction. An office with ten simultaneous calls on G.711 needs about one megabit per second of upload and download for voice alone. That is not much on most of today's connections, but the upload on some home connections is narrow, so it is worth checking. See Bandwidth.

Ports and the firewall

The control channel usually comes in on one fixed port. RTP, by contrast, uses a different port in every call from a wide range, because every call needs its own voice channel. So "opening the phone's port" in the firewall is not enough: if the range of voice ports is blocked, the call will ring and be answered, and nothing will be heard in it.

With a cloud PBX, the phone is the one that opens the connection outward, so in most offices you do not need to open any port from outside. What does matter is that the firewall does not block outgoing traffic in this range, and that the router does not delete connections too quickly. See Firewall and Ports.

Diagnosis table: what you hear and what it means

A rule of thumb: if the call is not created at all, look at SIP. If the call is created and the voice is bad, look at RTP.

An example from the field

At the office of the nonprofit "Yad BeYad LeShachen" (a made-up name), they complained that incoming calls sounded fine, but in some outgoing calls the other side could not hear the secretary. The phones rang and were answered with no problem, meaning SIP worked.

On inspection, it turned out that the router installed not long before came with SIP ALG enabled. It "fixed" the phone's business card, and sent its voice to a port that was not open. After turning the setting off and making test calls in both directions, the problem disappeared. No phone was replaced.

What the phone does to hide problems

Since RTP does not fix faults on the way, the phone on the receiving side does a few things to make the call sound as good as possible:

• Jitter buffer: the phone holds a few packets before playing them, which evens out an uneven pace. A larger buffer evens out more, but adds delay. Most devices adjust its size automatically.
• Loss concealment: when a packet is missing, the phone "invents" in its place a voice similar to what it heard a moment ago. A small, scattered loss is hardly noticeable.
• Silence detection: on some devices, when nobody is speaking, fewer packets are sent. The other side hears "comfort noise" instead of complete silence, so it does not think the call was cut off.

These tools help, but they have a limit. When the loss or jitter is too large, no buffer will save the call, and you need to deal with the network itself, for example with traffic prioritization (QoS).