RTP
"RTP Read too short" in Asterisk
Asterisk received an RTP packet that was too short to be a valid one and threw it away. The important question is not what one packet was, but how many there were.
What it looks like in the log
[2026-08-17 12:38:26] WARNING[9931][C-00001683] res_rtp_asterisk.c: RTP Read too short
What it means
A valid RTP packet has a minimum header size. Anything shorter cannot be parsed, so Asterisk discards it and logs this warning rather than trying to interpret it.
An isolated occurrence is usually a transient network glitch and safe to ignore. A stream of them on one call is a real media-path problem, and the caller is very likely hearing it - heavy runs of this warning tend to coincide with the calls users report as choppy audio or one-way audio.
Most common causes
-
01Ordinary transient packet corruption
One or two over a day of calls is background noise on any real network.
-
02MTU and fragmentation problems
A path that fragments RTP and reassembles it badly produces short reads repeatedly on the affected route.
-
03A far end sending malformed packets
Some devices and gateways emit keepalives or comfort-noise frames that Asterisk reads as truncated RTP.
-
04NAT devices rewriting packets
ALG features on consumer routers rewrite SIP and sometimes damage the media alongside it. Disabling SIP ALG is a standard first move.
-
05A saturated or lossy link
Heavy loss shows up as short reads among other symptoms, usually alongside audio complaints that started at the same time.
How to tell which one it is
Count occurrences per call. A handful across a whole day is noise. Dozens on one call is a problem, and the calls with the most of them are the ones users complained about.
If they cluster on one trunk or one remote site, that path is the suspect. If they are spread evenly across everything, look at the box's own network interface and the switch it is on.
How to fix it
-
Ignore isolated occurrences
This is one of the warnings most worth not chasing when it is rare. Fixing noise costs time and changes nothing.
-
Disable SIP ALG on intermediate routers
It causes more problems than it solves and is a common source of mangled media.
-
Check MTU on the affected path
If short reads concentrate on one route, test for fragmentation along it before adjusting anything on the PBX.
-
Capture the media on a bad call
When it is frequent and localised, a packet capture on the affected leg identifies the sender of the malformed packets directly.