先把结论说清楚：RTP 环路（rtp loop）= 同一个 RTP 包被反复转发、在两个或多个节点之间来回兜圈，结果就是：
- 日志狂刷：
More than 30 duplicate packets detected, dropping - 延迟变大、抖动高、音质差
- 严重时把 rtpengine/服务器跑挂
下面按"原理 → 你的场景怎么发生 → 怎么排查"来讲。
一、RTP 环路的本质（简单说）
RTP 是 UDP、无连接、无确认 的，转发设备（rtpengine、Kamailio、NAT、路由器）只看：
- 目的IP:PORT（把包发过去）
- 很少校验：来源、是否已转发过、是否自己发出去又回来
只要出现：
A → B → A → B → ...
就形成 Layer-3/Layer-4 环路，RTP 包无限复制、转发、膨胀。
二、在你的架构里，RTP 环路是怎么发生的
你的拓扑（简化）：
UAC ↔ edge-kamailio/rtpengine ↔ 路由器 ↔ edge-kamailio/rtpengine ↔ UAS
(172.16.23.23) (10.141.10.0/24)SDP 被两次改写：
- 第一次过 edge：SDP 写 core 侧 IP（10.141...）
- 过路由器：不变
- 第二次回 edge：SDP 改写为 access 侧 IP（172.16...）
环路触发点：rtpengine 收到自己发出去的包
典型流程：
-
rtpengine 从 172.16.23.23:32512 发 RTP 给路由器/核心网
-
路由/转发规则又把这个包原路发回 给 rtpengine 的 10.141.10.55:32724
-
rtpengine 一看：这个端口是我在这个呼叫上的端口 → 又转发出去
-
于是：
rtpengine(172.16) → 路由 → rtpengine(10.141) → 路由 → rtpengine(172.16) → ...包不断回来 → duplicate packets → 日志告警、丢包、延迟。
为什么会这样（你环境里的几个原因）
-
两次 SDP 改写 + 双网卡路由折返
- rtpengine 有两个网口：
172.16.23.23（access）、10.141.10.55（core） - 呼叫走了一个"大三角"：UAC → access → core → access → UAS
- RTP 走同样路径时，从 core 口出去的包被路由回 core 口，形成 hairpin/loop。
- rtpengine 有两个网口：
-
rtpengine 端口切换 + 流识别混淆
日志：
Switching local interface to 172.16.23.23:32512 Switching local interface to 10.141.10.55:32724- 同一路呼叫，rtpengine 在两个网卡、两个端口之间来回切
- 内部流表把"自己发的包"当成"新收到的包"，再次转发 → 环路。
-
内核转发（xt_RTPENGINE）还没完全稳定/识别流
- 刚接通几秒是用户态转发，容易乱
- 内核规则还没下发或识别错了入接口 → 包又回用户态 → 反复转发。
三、为什么日志里看到 "duplicate packets"
rtpengine 对每个呼叫的 (SSRC, 端口对, 入接口) 做简单重复检测：
- 短时间内同一个 SSRC、同样方向收到 >30 个包，判定为 loop
- 直接丢包并打 WARNING：
More than 30 duplicate packets detected
这说明：环路已经发生，rtpengine 在主动止损。
四、和你看到的 "hairpin routing" 有什么区别
-
正常 hairpin（发夹） ：
UAC → rtpengine → UAS，只过一次 rtpengine
rtpengine 识别：入和出都是自己 → 直接内核转发，不循环。
-
你遇到的 loop ：
UAC → rtpengine(access) → 路由 → rtpengine(core) → 路由 → rtpengine(access) → ...
两次进入 rtpengine、跨网卡折返 → 真正的 RTP 环路。
五、简单总结（一句话）
你的 RTP 环路 = 双网卡 + 两次 SDP 改写 + 路由折返 → rtpengine 收到自己发出的包 → 反复转发 → duplicate 告警 + 延迟。