来自 VoIP 领域的一个问题。
NAT 后面的几个设备想要与发送方 IP 建立 UDP 连接。UDP 的 NAT 设置如下
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
设备向服务器发送 REGISTER 并建立 UDP 连接。通常的游戏如下：
->Proxy Authentication Required
<-REGISTER nonce
->OK
并且 99% 以上都被识别为 UDP 流。如果 SenderIP 现在每 60 秒发送一个 SIP 数据包，则连接始终与 UDP 流保持在同一端口上。我在 conntrack 中看到（例如，对于 2 个设备）：
udp 17 114 src=internalIP1 dst=SenderIP sport=5060 dport=5060 src=SenderIP dst=externalIP sport=5060 dport=8382 [ASSURED] mark=0 use=1
udp 17 119 src=internalIP2 dst=SenderIP sport=5060 dport=5060 src=SenderIP dst=externalIP sport=5060 dport=22919 [ASSURED] mark=0 use=1
但是，我（很少）遇到这种情况（这里 TTL 从 30 秒减少到 9 秒，无法识别为流）
udp 17 9 src=InternalIP dst=SenderIP sport=5060 dport=5060 src=SenderIP dst=ExternalIP sport=5060 dport=20932 mark=0 use=1
一分钟后：
udp 17 26 src=SenderIP dst=ExternalIP sport=5060 dport=20932 [UNREPLIED] src=ExternalIP dst=SenderIP sport=20932 dport=5060 mark=0 use=1
端口已关闭，SenderIP 无法访问设备。
当我分析此案例时，我看到此 dport (20932) 上有时间戳：
<-REGISTER:
15:17:41.728188 IP (tos 0x60, ttl 63, id 12923, offset 0, flags [none], proto UDP (17), length 621)
->Proxy Authentication Required:
15:17:41.732859 IP (tos 0x10, ttl 59, id 3219, offset 0, flags [none], proto UDP (17), length 527)
<-REGISTER with auth:
15:17:41.733459 IP (tos 0x60, ttl 63, id 12925, offset 0, flags [none], proto UDP (17), length 627)
->OK:
15:17:41.738826 IP (tos 0x10, ttl 59, id 3220, offset 0, flags [none], proto UDP (17), length 564)
在 conntrack 中我可以看到 TTL 9 秒，这不被识别为流：
udp 17 9 src=internalIP dst=SenderIP sport=5060 dport=5060 src=SenderIP dst=externalIP sport=5060 dport=20932 mark=0 use=1
总共只有 2100 个连接，因此不会达到限制。
为什么有些连接不能被识别为流？
将连接识别为 UDP 流的算法是什么？
在哪些情况下它可能失败？