H3C防火墙SIP语音卡顿排查实战从pcap抓包到ASPFQoS全链路解决2026年7月一、问题背景1.1 网络拓扑某企业使用H3C SecPath F1020防火墙作为互联网出口网关内网部署H3C PBX语音交换机通过SIP中继对接运营商。网络拓扑如下运营商SIP网关(180.106.8x.xx)|[互联网]|GE1/0/1 (WAN: 223.6x.1xx.1xx/30, 300M专线)[H3C SecPath F1020]GE1/0/6 (LAN: 192.168.1.1)|[内网交换机]|PBX(192.168.1.10) VoIP网关(192.168.1.9)1.2 故障现象SIP语音通话单方向卡顿听对方声音断断续续对方听自己正常问题只出现在外网通话内网分机互打完全正常偶尔出现通话中断带宽充足300M专线网络延迟和抖动均正常1.3 环境信息项目信息防火墙型号H3C SecPath F1020固件版本Comware 7.1.064 Release 9333P27WAN接口GE1/0/1 (223.68.1xx.1xx/30)LAN接口GE1/0/6 (192.168.1.1)PBXH3C U1910 (192.168.1.10)VoIP网关1016B4-160 FXS (192.168.1.9)运营商网关180.106.xx.xx专线带宽300Mbps二、排查过程2.1 第一步pcap抓包分析在PBX侧进行抓包分析RTP媒体流质量# 使用Wireshark统计 RTP RTP流分析# 发现下行方向丢包率约12%# RTP序号不连续574个包/分钟被丢弃抓包结论问题不在网络延迟或抖动而是有大量RTP包被丢弃。2.2 第二步防火墙性能检查排除防火墙性能瓶颈H3C display cpu-usageCPU usage: 4% # 正常H3C display memoryMemory usage: 68% # 正常H3C display session table countCurrent sessions: 2300 # 远低于上限CPU、内存、会话数均正常排除了防火墙性能不足的可能。2.3 第三步安全策略检查最初怀疑是安全策略未放行RTP端口于是配置了专用的语音安全策略# 创建地址对象object-group ip address obj-pbxnetwork host address 192.168.1.10object-group ip address obj-sip-gwnetwork host address 180.106.xx.xx# 创建服务对象object-group service obj-sip-udpservice udp destination-port 5060object-group service obj-rtp-udpservice udp destination-port range 10000 65535# 创建安全策略security-policy iprule name Allow-Voice-Outsource-zone trustdestination-zone untrustsource-ip obj-pbxdestination-ip obj-sip-gwservice obj-sip-udpservice obj-rtp-udpaction passrule name Allow-Voice-Insource-zone untrustdestination-zone trustsource-ip obj-sip-gwdestination-ip obj-pbxservice obj-sip-udpservice obj-rtp-udpaction pass注意这一步虽然配置正确但并没有解决问题。因为RTP端口是动态协商的静态放行端口范围并不适用于SIP动态媒体通道。2.4 第四步启用SIP ALG检查并启用NAT层的SIP ALG功能H3C display nat algNAT ALG: SIP Enable # 已启用SIP ALG已经启用但问题依旧。这是因为NAT ALG只处理SIP信令的NAT转换并不负责为RTP动态通道创建会话。2.5 第五步关键发现——首报文状态检查错误查看防火墙丢包统计终于发现关键线索H3C display firewall statistics首报文状态检查错误: 574 packets/min警告根因找到了防火墙首报文状态检查丢弃了大量RTP包。RTP是SIP动态协商的媒体通道防火墙没有在会话表中为这些动态端口创建会话条目导致RTP包被当作非法首包丢弃。这就是为什么内网通话正常——不经过防火墙听对方卡——下行RTP包被防火墙丢弃对方听自己正常——上行RTP包可能恰好匹配了某些会话丢包率574包/分钟约等于12%与pcap分析结果完全吻合。三、解决方案3.1 ASPF配置核心修复3.1.1 什么是ASPFASPFAdvanced Stateful Packet Filter高级状态包过滤是H3C防火墙的特有功能专门处理SIP、FTP等多通道协议。它能监控SIP信令自动为RTP媒体流创建临时会话通道确保动态协商的RTP端口不被防火墙状态检查丢弃。提示ASPF与NAT ALG是两个不同的功能NAT ALG处理SIP信令的NAT转换ASPF处理RTP动态通道的会话创建。两者必须同时配置。3.1.2 创建ASPF策略# 创建ASPF策略1检测SIP协议aspf policy 1detect sip注意命令语法陷阱命令是 aspf policy 1空格不是 aspf-policy 1连字符。后者在Comware 7上会报 Unrecognized command。3.1.3 在域间应用ASPF策略ASPF策略必须在两个方向都应用缺一不可# Trust→Untrust 方向内网到外网zone-pair security source trust destination untrustaspf policy 1# Untrust→Trust 方向外网到内网—— 这一步是关键zone-pair security source untrust destination trustaspf policy 1警告如果只在Trust→Untrust方向应用ASPFRTP下行包仍然会被丢弃因为ASPF需要双向检测才能正确创建回程会话。这是最容易遗漏的配置。3.1.4 保存配置H3C save force3.2 QoS配置语音优先保障3.2.1 配置DSCP标记为语音流量标记DSCP EF(46)优先级确保在网络拥塞时语音流量优先转发# 定义语音流量ACLacl advanced 3000rule 0 permit udp source 192.168.1.10 0.0.0.0destination-port range 10000 65535rule 5 permit udp destination 192.168.1.10 0.0.0.0destination-port range 10000 65535# 创建QoS分类traffic classifier c-voiceif-match acl 3000# 创建QoS行为标记DSCP EFtraffic behavior b-voiceremark dscp ef# 创建QoS策略qos policy p-voiceclassifier c-voice behavior b-voice# 在LAN口入方向应用interface GE1/0/6qos apply policy p-voice inbound3.2.2 保障带宽建议建议在WAN口配置带宽保障# 每路G.711语音约需80kbps含IP头# 每路G.729语音约需24kbps含IP头# 建议保障512Kbps带宽约6路G.711或20路G.729# 可根据实际并发通话数调整3.3 编码优化建议G.729当前使用G.711编码建议在PBX上切换到G.729编码编码带宽(含IP头)抗丢包能力音质推荐G.71180kbps/路差(丢包3%明显卡)最好不推荐WANG.72924kbps/路强(丢包5%仍可接受)良好推荐WAN提示G.729编码需要在PBX(192.168.1.10)上配置不是在VoIP网关(192.168.1.9)上。1016B4-160网关是FXS模拟电话网关不负责编码转换。四、踩坑记录4.1 NAT ALG ! ASPF最常见的误区是认为启用了SIP ALG就够了。实际上NAT ALG (nat alg sip)只处理SIP信令中的NAT地址转换将内网IP替换为公网IPASPF (detect sip)监控SIP信令自动为RTP动态端口创建会话通道两者功能完全不同缺一不可。本案例中NAT ALG已启用但问题依旧根本原因就是缺少ASPF配置。4.2 ASPF必须双向应用ASPF策略必须同时在Trust→Untrust和Untrust→Trust两个方向应用。如果只在一个方向应用只应用Trust→Untrust上行RTP正常下行RTP仍被丢弃只应用Untrust→Trust效果类似仍有一个方向的RTP被丢弃必须双向应用ASPF才能正确追踪SIP会话状态并创建双向RTP通道。4.3 命令语法aspf policy 1 不是 aspf-policy 1在H3C Comware 7上# 正确写法aspf policy 1detect sip# 错误写法报 Unrecognized commandaspf-policy 1detect sip注意不同版本固件的命令格式可能有差异配置前务必查阅对应版本的命令参考手册。4.4 Web UI无法配置ASPFH3C Comware 7的Web管理界面中安全策略编辑器和安全域编辑器都没有ASPF/状态检测的配置选项。ASPF只能通过CLI在zone-pair上配置。如果只依赖Web UI将永远找不到这个配置入口。4.5 静态放行RTP端口范围无效有人会在安全策略中放行10000-65535的UDP端口范围来解决RTP问题。这种做法治标不治本放行了所有高端口降低了安全性可能无效如果防火墙状态检查在安全策略之前执行包已经被丢弃了不可靠SIP协商的RTP端口可能不在10000-65535范围内正确的做法是使用ASPF自动为SIP协商的RTP端口创建会话。五、效果对比指标修复前修复后(ASPFQoS)RTP丢包率~12% (574包/分钟)0%通话质量严重卡顿清晰流畅单向通话听对方卡对方听正常双向正常内网通话正常正常(不受影响)防火墙CPU4%4%(无变化)安全影响无ASPF仅为SIP动态通道创建临时会话安全性可控修复步骤顺序和效果步骤操作效果1启用SIP ALG无改善(ALG只处理NAT转换)2静态放行RTP端口无改善(状态检查先于策略匹配)3Trust→Untrust应用ASPF部分改善(上行RTP正常下行仍丢包)4Untrust→Trust应用ASPF通话质量大幅改善基本正常5QoS DSCP EF标记拥塞时语音优先效果更稳定六、排查方法论总结本次排查遵循了”从数据到根因”的逐层排查原则6.1 五层排查法层级检查项工具/命令本案例结果1-物理层接口状态、错包统计display interface正常零丢包2-网络层路由、ACL、NATdisplay acl, display nat session策略配置正确3-安全层状态检查、会话表display firewall statistics发现574包/分钟被丢弃4-应用层SIP ALG、ASPFdisplay nat alg, display aspfASPF未配置5-QoS层队列、带宽保障display qos policy无QoS配置6.2 关键命令速查#查看防火墙丢包统计最关键display firewall statistics#查看会话表确认RTP会话是否建立display session table ipv4 destination-ippbx-ip#查看ASPF配置display aspf policy#查看域间ASPF应用display zone-pair security#查看NAT ALG状态display nat alg#查看QoS策略display qos policy6.3 排查思路先确认现象单通/双通、内网/外网缩小排查范围再排除硬件CPU、内存、接口错包然后看丢包统计防火墙统计是金矿不要忽略区分ALG和ASPFNAT层和应用层是两套机制双向验证ASPF/QoS都要检查双向配置七、完整配置参考7.1 ASPF配置# 创建ASPF策略aspf policy 1detect sip# Trust→Untrust 应用zone-pair security source trust destination untrustaspf policy 1# Untrust→Trust 应用关键zone-pair security source untrust destination trustaspf policy 17.2 QoS配置# 定义语音流量ACLacl advanced 3000rule 0 permit udp source 192.168.1.10 0.0.0.0destination-port range 10000 65535rule 5 permit udp destination 192.168.1.10 0.0.0.0destination-port range 10000 65535# QoS分类和行为traffic classifier c-voiceif-match acl 3000traffic behavior b-voiceremark dscp efqos policy p-voiceclassifier c-voice behavior b-voice# 在LAN口入方向应用interface GE1/0/6qos apply policy p-voice inbound7.3 安全策略可选ASPF已自动处理RTP通道security-policy iprule name Allow-SIP-Outsource-zone trustdestination-zone untrustsource-ip obj-pbxdestination-ip obj-sip-gwservice obj-sip-udpaction passrule name Allow-SIP-Insource-zone untrustdestination-zone trustsource-ip obj-sip-gwdestination-ip obj-pbxservice obj-sip-udpaction pass提示启用ASPF后无需再静态放行RTP端口范围ASPF会根据SIP信令自动创建RTP会话通道。八、总结与建议8.1 核心结论SIP语音卡顿的根因是防火墙未配置ASPF导致RTP动态媒体通道的包被状态检查丢弃。NAT ALG只处理信令NAT转换ASPF才负责RTP通道会话创建。8.2 最佳实践建议部署SIP语音时必须同时配置NAT ALG和ASPF缺一不可ASPF策略必须在双向zone-pair上应用为语音流量配置QoS DSCP EF标记确保拥塞时优先转发WAN环境优先使用G.729编码24kbps/路节省带宽且抗丢包能力更强定期检查防火墙丢包统计这是发现隐藏问题的金钥匙不要完全依赖Web UI关键配置往往只能在CLI完成8.3 排查口诀先看丢包统计再查会话表ALG管NATASPF管通道双向都要配命令别写错。8.4 参考文档H3C SecPath防火墙配置指南 - ASPF配置H3C Comware 7 安全配置手册 - SIP ALG与ASPFRFC 3261 - SIP: Session Initiation ProtocolRFC 3550 - RTP: A Transport Protocol for Real-time Applications— 全文完 —AIGC标识: 89b81827-0006-4c8b-99e8-f7c7964e075f