From 2449595b5592eba493eb59da59ce26df59eff889 Mon Sep 17 00:00:00 2001 From: Richard Fuchs Date: Wed, 8 Jul 2026 09:16:47 -0400 Subject: [PATCH] MT#55283 update docs Closes #2135 Change-Id: Idaca5cfb529e39726016115af99933393e91e5bc (cherry picked from commit 2106ea445b4c50e6b78b9f491714244397ba2d07) --- docs/usage.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/docs/usage.md b/docs/usage.md index dd28cf46d..5bc616956 100644 --- a/docs/usage.md +++ b/docs/usage.md @@ -24,8 +24,7 @@ For these reasons, *rtpengine* provides a kernel module to offload the bulk of t duties from user space to kernel space. Using this technique, a large percentage of the overhead can be eliminated, CPU usage greatly reduced and the number of concurrent calls possible to be handled increased. -In-kernel packet forwarding is implemented as an *nftables* module -(or more precisely, an *x\_tables* module). As such, it requires two parts +In-kernel packet forwarding is implemented as an *nftables* module. As such, it requires two parts for proper operation. One part is the actual kernel module called `nft_rtpengine`. The second part is a rule in the local *nftables* chains that gets hit by UDP packets so that they can be processed by the kernel module. @@ -38,7 +37,7 @@ In short, the prerequisites for in-kernel packet forwarding are: auto-loading when correctly installed. 2. A rule added to an *nftables* chain that gets called by an *input* hook in the *filter* table, which sends packets - to the `RTPENGINE` target. This rule should be limited to UDP packets, but otherwise there + to the `rtpengine` target. This rule should be limited to UDP packets, but otherwise there are no restrictions. The *rtpengine* daemon manages creation and deletion of this rule. 3. The `rtpengine` daemon must be running. 4. All of the above must be set up with the same forwarding table ID (see below). @@ -50,7 +49,7 @@ The sequence of events for a newly established media stream is then: based on the info received from the SIP proxy. Only userspace forwarding is set up, nothing is pushed to the kernel module yet. 3. An RTP packet is received on the local port. -4. It traverses the *nftables* chains and gets passed to the *xt\_RTPENGINE* module. +4. It traverses the *nftables* chains and gets passed to the *nft\_rtpengine* module. 5. The module doesn't recognize it as belonging to an established stream and thus ignores it. 6. The packet continues normal processing and eventually ends up in the daemon's receive queue. 7. The daemon reads it, processes it and forwards it. It also updates some internal data.