Undestanding <<Too many packets in UDP receive queue>>

[Myng]

Hello, 
I usually get the error  "Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible" 

I read from other mail list, but I still not clear, Could any help me to explain:

* It is too many UDP for NG package or RTP?
* I saw people mention about loop, what exactly loop here? 
* Other comment. it is sign of overload, I do monitoring server, but I did not see any load issue on CPU/memory/network bandwidth, do I miss something else?

Thanks for you help. 

[Richard Fuchs]

On 25/06/2025 03.58, Myng wrote:
> * It is too many UDP for NG package or RTP?

It is relevant to RTP (media) sockets only.

> * I saw people mention about loop, what exactly loop here?

It's about RTP forwarding loops, cases where rtpengine starts sending
media to itself, in a loop (i.e. call leg X forwards to call leg Y and
call leg Y forwards to call leg X). This can happen by mistake if output
SDPs from rtpengine are fed back into rtpengine as input SDPs.

> * Other comment. it is sign of overload, I do monitoring server, but I
> did not see any load issue on CPU/memory/network bandwidth, do I miss
> something else?

These are probably the most common causes, possibly disk I/O if memory
is low and the system starts swapping. VM environments can also
contribute to this, when packets are delivered to the virtual network
stack in bursts, and/or the scheduler not allowing the virtual CPU to
run continuously.

Cheers

[Tommy]

Well explained, Thank so much for your answer.

Can unwanted traffic like STUN or unauthenticated RTCP cause the "Too many packets in UDP receive queue" error? Do you know of any other possible causes?

[Richard Fuchs]

On 28/06/2025 11.47, Tommy wrote:

Well explained, Thank so much for your answer.

Can unwanted traffic like STUN or unauthenticated RTCP cause the "Too many packets in UDP receive queue" error? Do you know of any other possible causes?

All types of packets should be processed swiftly and immediately without the thread getting blocked, so no, they should not lead to the receive queue getting full.

If you use a Redis HA backend, a slowly responding Redis server could cause threads getting blocked.

If you can reproduce this, or if it occurs often enough, you can try Wiresharking the network and see if you can identify the packets in question, or possibly run rtpengine under strace, although that's more intrusive and so probably not an option for loaded production systems.

Cheers