Understanding RTP and Audio Streams in VoIP Calls

RTP, the Real-time Transport Protocol, is the protocol that carries the actual voice in a VoIP call. While SIP sets the call up, RTP delivers the audio as a continuous stream of small UDP packets, usually one every 20 milliseconds in each direction. Each packet carries a chunk of encoded audio plus a header with a sequence number and a timestamp. The receiver uses those to put packets in order, notice gaps and play the audio at a steady pace. RTP is defined in RFC 3550. Its companion RTCP reports on quality. Where the packets go is decided in the SDP exchanged during the SIP INVITE.

What is in an RTP packet?

An RTP packet has a 12-byte fixed header followed by the payload.

• Version, padding, extension and CSRC count in the first byte. Version is always 2.
• Marker bit. Set on the first packet after a silence period, so the receiver can reset its playout timing.
• Payload type. A 7-bit number identifying the codec. Static types from RFC 3551 include 0 for G.711 ulaw (PCMU) and 8 for G.711 alaw (PCMA). Dynamic types from 96 to 127 are assigned in the SDP, for example 111 for Opus.
• Sequence number. Increments by one per packet. Lets the receiver detect loss and reorder.
• Timestamp. Increments by the number of samples in the packet, 160 for 20 milliseconds at 8 kHz. Lets the receiver schedule playback.
• SSRC. A random 32-bit identifier for this stream. Changes if the source restarts.

The payload is the codec output for that interval. For G.711 at 20 milliseconds that is 160 bytes. With the 12-byte RTP header, 8-byte UDP header and 20-byte IPv4 header, the packet on the wire is 200 bytes. Fifty packets per second gives 80 kbit/s per direction, which is why G.711 calls are often quoted at around 80 to 90 kbit/s rather than the codec's 64 kbit/s. The VoIP bandwidth calculator works this out for different codecs and packet intervals.

How do both sides know where to send RTP?

The SIP INVITE and its 200 OK carry an SDP body as defined in RFC 8866. Two lines matter for RTP routing.

c=IN IP4 203.0.113.20
m=audio 10000 RTP/AVP 111 0 8
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000

The c= line gives the IP address and the m= line gives the port and the list of payload types the sender can receive. Each side sends its RTP to the address and port the other side advertised. RTCP conventionally uses the next odd port, 10001 here, unless the SDP says otherwise. Asterisk-based PBXs use UDP 10000 to 20000 for RTP by default; providers and softphones use their own ranges.

What does RTCP do?

RTCP, the RTP Control Protocol, runs alongside RTP on its own port. Each side periodically sends sender and receiver reports containing packet counts, the fraction of packets lost, the cumulative loss, the highest sequence number seen and an estimate of interarrival jitter. The reports let endpoints and monitoring systems measure call quality without inspecting the audio. RTCP uses a small fraction of the bandwidth. RFC 3550 recommends keeping it to about 5 percent of the session bandwidth. Some softphones display the loss and jitter figures from RTCP in a call statistics view.

How does the receiver handle timing problems?

Packets do not arrive at a perfectly steady rate. Network queues add varying delay, called jitter. Some packets are lost. Some arrive out of order. The receiver deals with this in three ways.

1. Jitter buffer. Incoming packets are held for a short time, often 20 to 60 milliseconds, before playback. This gives late packets time to arrive. Adaptive jitter buffers grow when the network is bad and shrink when it improves.
2. Reordering. The sequence number lets the buffer place an out-of-order packet correctly.
3. Loss concealment. When a packet is missing, the decoder fills the gap. Simple codecs repeat or interpolate the previous audio. Opus has built-in packet loss concealment and can include redundant data to recover from loss.

The trade-off is delay. Every millisecond of buffer is a millisecond of extra latency. ITU-T G.114 recommends keeping one-way delay below about 150 milliseconds for most conversations, so the buffer is kept as small as the network allows.

How do keypad tones travel over RTP?

When you press a key during a call, for example to navigate a menu, the tone must reach the far end. Sending the actual audio tone through a compressed codec can distort it. RFC 4733, which replaced RFC 2833, defines a special RTP payload that carries the digit as an event, with its duration and volume, instead of audio. The SDP advertises it with a dynamic payload type and a=rtpmap:101 telephone-event/8000. Most PBXs and softphones use this method; Asterisk calls it rfc2833 or rfc4733 in its DTMF mode setting. SIPdia, for instance, sends DTMF as RTP events of this kind. The alternatives are in-band audio tones and SIP INFO messages, both of which are less reliable across different systems.

Why does one-way or no audio happen?

This is one of the most common VoIP problems, and it is usually caused by NAT or a firewall. The SDP carries the IP address and port the sender believes it has. Behind a home or office router that is a private address, such as 192.168.1.20. The remote side sends RTP to that address and the packets go nowhere. Signalling worked, the call shows as connected, but one or both sides hear nothing.

Several mechanisms address it.

• Symmetric RTP on the server. The PBX ignores the address in the SDP and instead sends RTP back to wherever the client's RTP came from. Asterisk does this with rtp_symmetric=yes and the related force_rport and rewrite_contact options on the PJSIP endpoint, or nat=yes on older chan_sip.
• STUN. The client asks a public STUN server which public address and port its RTP socket maps to, and puts that in the SDP. This works for many consumer routers but not for symmetric NAT.
• ICE. Interactive Connectivity Establishment, defined in RFC 8445, gathers every candidate address (local, STUN-derived and optionally relayed through TURN), lists them all in the SDP and then tests connectivity between each pair until one works. It is the most robust method and the standard in WebRTC. Both ends must support it.
• Media relay. The server stays in the media path and relays RTP between the parties, which hides each party's NAT from the other. Asterisk does this when direct media is turned off for the endpoint (direct_media=no in PJSIP, where the default is yes), and it also stays in the path whenever it needs the audio, for example to transcode or record.

Enabling STUN and ICE in the softphone and setting the NAT options on the PBX resolves most one-way audio cases. For a step-by-step checklist, see How to fix one-way audio in VoIP calls.

Does RTP encrypt the audio?

No. RTP payloads are plain. Anyone who can capture the packets can decode and listen to the call. SRTP adds encryption and authentication to each packet. Read What is SRTP? for how it works and why it pairs with TLS signalling.

Next steps

Use the VoIP bandwidth calculator to estimate what your calls need. Then read SIP codecs explained to understand what goes inside each RTP payload, and What is SIP? for the signalling that sets the stream up.