FREQUENTIS内话和RS内话通过IP方式连接PAE电台异常的故障排查

FREQUENTIS内话和RS内话通过IP方式连接PAE电台异常的故障排查

方嵘滨

中南空管局技术保障中心 广东广州 510000

摘要

VOIP技术是基于IP网络，结合语音压缩算法，将数据打包处理，利用IP网络完成语音传输的技术。目前民航空管系统的IP设备依托ED137相关协议，各厂家设备在基础功能上均可以实现互通。

随着地空通信相关设备逐渐从模拟信号迈向VOIP，FREQUENTIS内话和RS内话分别作为某现场的主、备内话系统同PAE 2代电台进行VOIP的引接。在引接过程中出现了主用内话与电台建链失败的情况。

本文通过抓包分析出两套内话与电台连接时出现建链失败的原因，并找出解决方案。

关键字：VOIP，FREQUENTIS，RS，SIP，record-route

一 基本设备情况

某现场使用主用内话系统为FREQUENTIS内话系统，硬件版本为Rel 7.1，软件版本为ReV14.1；备用内话系统为RS内话系统，软件版本为R8.10。甚高频电台为PAE T6系列。网络连接如下图所示：FREQUENTIS内话使用GPIF5.41与电台建链，板卡设汇聚交换机的vlanif50为网关地址；RS内话由于系统内部已经设好网关，因此只能在RS交换机设置静态路由指向汇聚交换机的vlanif60；电台端将两个测试频率的电台网关设为汇聚交换机的vlanif50。至此3套设备在汇聚交换机上实现路由汇聚。

二 异常情况说明

对FREQUENTIS内话进行相应IP配置和RS内话进行相应IP配置后，与频率123的主备机和频率456的主备机均成功建立SIP链接且对空收发正常。之后一段时间后发现FREQUENTIS内话频率页RIF告警指示红绿闪烁，检查为FREQUENTIS内话与频率123接收机主机出现反复建链的情况，从主机切换至备机后接收正常。频率456收发主备机建链正常，测试收发正常。同时RS内话频繁出现FAILED_CALLS告警，告警每5分钟出现一次。该告警产生可能因为席位选中了不可用的频率或者电台服务器与外部IP电台建链异常。由于该段时间内，两套内话均做了较多的配置修改，且RS内话告警日志表示不明确，无法确定异常故障点，且当时无法明确两套内话的告警是否有关联。

图1：RS内话FAILED_CALLS告警日志

三 异常情况分析及解决方案

针对FREQUENTIS内话123频率接收备机重复建链的情况，在图1中汇聚交换机至收/发信机网口处抓包进行分析。其中21.5.25网段是电台端，21.5.16网段是FREQUENTIS内话网段，192.168.10.21是RS内话无线电服务器IP。对抓包内容进行分析如图2所示：对SIP包进行过滤后，经常出现电台端主动和内话端发起的bye的请求消息，其中原因为session pre-emption，该原因一般为会话被超控或者抢占。初步猜测是否因为有别的内话设备用高优先级强占导致。但该电台只接了文字所述的两套内话设备，不存在有高优先级强占或者到达SIP连接上限的情况。

图2 bye包报文

继续对抓包进行分析，通过追踪流的功能过滤出相同sip.CALL-ID的报文如图3所示。可以发现FREQUENTIS内话与电台之间的建链出现了RS内话的IP（192.168.10.21）。根据SIP建链的规则：1 内话发送请求消息invite给电台；2 电台回应200ok给内话代表电台成功响应；3 内话回复电台Ack完成建链。但是图如图3所示，建链的前2个步骤正常信息，但内话(101)将本应该发送给电台的ACK包发送给了RS的电台服务器。电台端没有收到FREQUENTIS内话的ACK包后多次重复发送200ok给内话，当超过一定时间后，电台认为没有完成SIP连接，因此主动发bye包给内话端。之后FREQUENTIS会重新向电台发起建链，就造成了在FREQUENTIS内话上RIF指示灯红绿闪烁反复告警的情况。

图3 对SIP流跟踪

查看具体报文，探究为何FREQUENTIS内话会将发给ACK报发给，查看具体报文，发现电台回包给内话的报文中附带了一个record-route字段，IP是RS的电台服务器IP。该字段功能是发送消息经过代理服务器时，会加上record-route，该字段是代理服务器在请求中增加的，用来强制会话中的后续请求经过本代理服务器。因此内话（101）会将之后的ACK包发给了RS的电台服务器，想通过RS的电台服务器作为代理服务器再发给FREQUENTIS内话。但是RS的电台服务器重新以FREQUENTIS的URI重新发起了invite链接。

图4 record-route字段

重新断开汇聚交换机与收/发信机网线，让两套内话与电台重新建链。频率123和频率456与飞坤内话均出现了RIF红绿闪烁情况。如图5所示，RS的电台服务器发送给电台的invite包里就已经附带了record-route字段。理论上电台对record-route字段的处理只会针对同一条session，但应未知原因造成电台回复给FREQUENTIS内话的200ok包里带了record-route字段。且如图5所示，RS的电台服务器发的是invite包而不是ack包，invite里是用frq这个uri向电台发起请求。由于RS内话里没有frq这个uri的相关设置，因此会导致RS内话频繁出现FAILED_CALLS告警。同时电台一直没收到FREQUENTIS内话发送的ACK包导致FREQUENTIS内话重复建链。

图5 RS发起的invite包

SIP建链完成后只会有R2S保活报并不会有新的SIP报文，因此当RS内话与电台先建链，FREQUENTIS内话与电台建链由于电台会回复附带record-route字段的200ok包，因此导致飞坤内话会重复建链。当FREQUENTIS内话先与电台建链，则不会受到record-route字段的影响。

至此确定了问题产生的主要原因是由于电台对record-route字段的处理不当造成。次要原因是由于RS内话的电台服务器发起建链时，必带record-route字段，且无法通过修改设置的方式删除。通过查询PAE电台厂家为电台固件版本较旧导致，可通过升级电台固件版本解决该问题。

四 总结

该问题的发现存在偶然性，只有当RS内话先于FREQUENTIS内话与电台建链，才会导致该问题的出现。VOIP排故相较于模拟内话排故较为复杂，需要了解SIP建链流程，了解SIP的协议头格式内容才可以较为准确的定位到故障点。