1. 项目概述为什么信创环境下的IP话机录音突然成了刚需最近不少做统一通信的老朋友都在问我同一个问题信创电话助手这一版到底把IP话机录音做成什么样说实话这个功能在传统呼叫中心里早就是标配但在信创环境下反而变成了一个需要专门立项去啃的硬骨头。原因不复杂录音这个事看着简单实际上涉及话机协议兼容、媒体流转发、国密加密、国产数据库存储、审计合规这整整一条链路每一环在国产化软硬件上都需要重新验证和适配。这篇文章想跟你聊的就是我们在信创电话助手里落地全新IP话机录音方案时踩过的坑、做过的选型对比和最终敲定的工程实现。适合三类人看一类是把IP话机录音列为信创项目验收项的甲方技术负责人一类是正在给国产软交换或IPPBX做配套开发的小伙伴还有一类就是对“信创产品目录”里录音类模块感到陌生、想快速上手的集成商朋友。不管你是准备采购评估还是自己动手集成读完至少能搞清楚该准备什么环境、软件要怎么做兼容性适配、上线后遇到录音文件缺失要怎么排查。先给一个总体的结论这版录音方案没有走传统的端口镜像路线而是以SIP媒体旁路为核心叠加话机侧主动上报作为备用通道整套服务跑在信创用户助手统一底座上存储、加密、审计跟信创适配及安全管理模块做了深度打通。这么设计的原因很简单——客户那里的话机品牌五花八门有的是老牌国产话机有的是白牌代工单纯依赖某一家的SDK根本不现实。与其跟每一家话机厂商死磕接口不如在媒体层做拦截统一处理RTP流把兼容性问题在上游一次性解决。2. 录音方案的技术选型与架构拆解2.1 三条主流录音技术路线我为什么没有选前两条做IP话机录音业内主流的方案无非三条交换机端口镜像抓包、话机SDK/API录音、SIP媒体旁路。我逐个说一下实测感受。端口镜像的方案原理是在交换机上把话机所在端口的流量镜像一份到录音服务器录音服务器抓包后还原出RTP音频。这套方案的最大优点是不管话机是什么牌子只要走标准SIP和RTP协议就能录部署思路跟传统模拟中继录音差不多老工程师很容易接受。但痛点同样突出第一它只能录单向或者双向混音很难拿到高音质分轨第二现在不少政企内网做了VLAN隔离和加密传输镜像口抓到的包经常是加密后的媒体流还原不出人声第三镜像流量会占用大量带宽录音服务器网卡稍弱就会出现丢包音频里全是杂音。话机SDK/API录音是让话机厂商提供接口话机本地录制后上传录音文件。好处是音质好、能拿到通话双方分轨而且话机自己录自己不用额外搭媒体服务器。坏处是国产话机的SDK质量参差不齐有的支持SIP话机但不支持DSS按键联动有的赠送版SDK里录音文件只保留七天更麻烦的是话机固件一升级接口行为就变你需要跟着每个厂商的版本做回归测试工作量非常失控。我们一开始在某家国产话机上做了试点结果发现同一型号不同批次固件的录音文件名规则都不同直接劝退。SIP媒体旁路是让录音服务器以SIP B2BUA或者媒体代理的身份插入通话链路SIP信令从录音服务器转发RTP媒体也强制经过录音服务器中转在中间节点直接抓取音频流。这条路最大的好处是话机只需要支持标准SIP协议即可不依赖具体厂商的私有SDK同时录音服务器天然拿到的就是完整媒体流转码、加密、混音都由你说了算。缺点是媒体路径变长多一跳就会引入转发延迟对服务器的转发性能有要求。这个缺点在信创服务器上其实可以接受因为现在单台主流ARM或x86服务器处理并发通话的媒体转发能力完全够用。2.2 方案选型背后的关键决策逻辑选型时我给自己定了三条硬标准按优先级排列兼容性大于音质音质大于成本成本大于部署复杂度。端口镜像虽然部署成熟但碰到加密通话就抓瞎在信创项目里客户环境往往已经做了国密加密传输这条直接废掉话机SDK音质最好但国产话机型号太多适配周期和售后成本不可控SIP媒体旁路在标准SIP协议下覆盖大部分国产话机而且不触碰终端固件不需要跟每个厂商做绑定认证落地节奏最快。再叠加信创目录和信创产品目录的准入要求方案还得满足国产密码算法支持、安全审计、日志留存这几个硬指标。SIP媒体旁路架构里RTP流在录音服务器本地落盘加密算法、密钥管理、访问控制都能做到统一管控完全在产品内部闭环不需要依赖外部系统。相比之下端口镜像抓包做合规审计时还得额外装一套抓包分析工具审计链路不完整很难通过信创适配及安全管理的验收。最后说一句关于信创实时云渲染和信创魔盒官网这些同生态产品。它们跟IP话机录音的关系在于信创电话助手并不是孤立的一个小工具而是信创用户助手生态里的一个业务模块。录音模块生成的媒体文件和索引数据可以同步给云渲染做可视化大屏展示也可以通过统一平台发布到信创魔盒官网的案例库。所以从架构第一天起录音模块的数据模型就留了对外接口字段方便后续跟其他生态模块联动这是很多人容易忽略的设计点。3. 核心功能细节与录音链路实现3.1 录音触发条件与通话状态机设计录音不是只要通话就录那样会录进来一堆呼叫中心内部的坐席转接、振铃提示音存储浪费不说审计里还全是垃圾文件。我们按照通话状态机来设计触发条件一共定义了五个核心状态空闲、振铃、通话中、保持、释放。实际触发规则是这样的当主叫拨号后被叫侧开始振铃此时不录音只有被叫摘机、双方媒体流建立成功后才开始录音。如果遇到呼叫转接检测到SIP REFER或者INVITE re-INVITE后保持原录音文件不中断再为转接后的新会话创建分段文件如果通过呼叫保持功能把通话挂起再恢复保持期间会暂停写入并打一个时间戳标记恢复后继续写入同一个录音文件。通话结束后录音服务收到BYE或者检测到RTP超时就停止写入并计算录音时长。这里有一个容易踩坑的点很多标准话机不发送BYE而是直接断开网络或者断电。如果录音服务纯靠SIP信令判断通话结束会残留大量半开文件。我们的处理方式是双保险信令判断之外再加一个RTP超时扫描任务超过30秒没有收到RTP包就关闭当前文件并标记为“异常中断”。这个参数不要设太短否则遇到正常的长时间静默会被误判也不要太长否则会话挂断后录音文件迟迟不落库用户在前台一直看不到记录。3.2 录音文件的加密、存储与索引设计录音文件的格式我们默认采用两种通道标准音频格式用WAV或者PCM长期归档用压缩后的AAC或者OPUS。为什么不直接全量存WAV因为信创服务器上磁盘空间有限64kbps码率的AAC相比原始WAV大概能省80%的容量以8路并发每天8小时通话量来算一年能省出几个TB的存储。但AAC是有损压缩遇到需要作为法律证据的合规录音我们提供“无损PCM有损AAC双份存储”模式由管理员在策略里按需开启。文件落盘前必须做加密。我们采用国密SM4对录音文件主体进行加密密钥由密钥管理服务统一分发文件存储层看到的都是密文即使有人拖走磁盘也还原不出内容。加密后的录音文件命名规则是“通话ID-时间戳-话机分机号-会话序号”所有索引信息写入国产数据库比如达梦或者人大金仓不直接依赖文件目录结构。也就是说上层应用查询录音只查数据库索引不直接扫磁盘目录这样既能支持按分机、按时间、按主被叫号码多维检索也方便数据库做备份和迁移。索引字段我们也做了冗余设计除了基本的主被叫号码、通话时间、时长、坐席工号之外还预留了“自定义标签”字段。比如客户的项目里经常要按客户合同号、工单号来检索录音这个字段就能派上用场。不要小看这个设计很多成品录音设备只能按号码查根本没法按业务维度归档后期做服务质量分析时非常痛苦。3.3 与信创用户助手及安全管理模块的集成方式信创电话助手不是一套独立安装的裸软件它运行在信创用户助手的统一框架内录音模块需要跟身份认证、权限管理、审计日志三个基础模块打通。身份认证这块录音服务的所有API调用统一走OAuth2.0令牌机制令牌由用户助手的安全中心签发录音文件查询页面的每次操作都要校验当前用户的角色权限。权限管理的粒度我们做到了分机级也就是说普通坐席只能查询自己名下的录音团队主管可以查整个分组的录音管理员才能删除和导出录音文件。删除操作不会直接物理删除文件而是先标记“待清理”保留90天后由定时任务彻底清除避免误删后无法恢复。审计日志方面录音模块每次查询、播放、下载、导出动作都会写入安全审计日志内容包括操作人、操作时间、涉及的通话ID、IP地址和操作结果。这些日志会和通话录音文件一同纳入信创适配及安全管理模块的合规检查范围审计人员可以通过统一界面做回溯。这一点特别重要因为很多项目在过检时最常被问到的就是“谁能听录音、谁导出了录音、导出后去了哪里”没有日志支撑安全性说不清楚。4. 实操过程从部署到上线的完整复现4.1 部署环境的硬件配置与国产化组合建议先说硬件配置我们压测下来录音模块的算力消耗大头在RTP转发和转码所以CPU主频比核心数更重要。建议最低配置是8核心CPU、16GB内存、1TB可用磁盘建议SSD做热数据缓存HDD做归档存储。如果并发通话超过50路CPU升级到16核心内存32GB。这里的核心参数计算公式可以这样估算一路G.711编码的RTP流约为80kbps8路并发24小时录音产生的裸数据量大约是80kbps / 8 10KB/s每小时36MB8路24小时就是36MB×8×246912MB约6.75GB。如果转成AAC 64kbps容量直接降到约5.4GB的一半以下这就是为什么我们建议归档层做压缩存储。操作系统层面我们分别在麒麟V10和统信UOS上做过完整验证录音服务的核心组件全部使用C和Java编写不依赖任何Windows专属动态库所以迁移非常顺畅。数据库建议优先考虑达梦或者人大金仓如果项目里还没有强制要求用PostgreSQL兼容模式也可以跑通。中间件如果涉及消息队列建议用东方通TongLinkQ我们兼容了标准JMS协议其他国产MQ也能接入。国产话机兼容性是我们花了最多时间测试的环节。测试过的型号包括华为、中兴、亿联、潮流、方位这几家在信创目录里常见的品牌以及若干白牌SIP话机。结论是基于标准SIP协议的话机基本都能正常录音但不同话机在DTMF传输方式、编解码优先级、SIP注册保活时长上存在一定差异需要在开局时统一配置。话机品牌测试型号录音兼容性主要注意点华为eSpace系列正常需关闭机内加密中兴8820系列正常编解码需固定为G.711亿联T4/T5系列正常需配置远程抓包许可潮流GXP系列正常支持真实ACK无特殊配置方位X系列基本正常个别固件需升级4.2 录音服务的安装与参数配置步骤这里我把我们实际执行的部署步骤整理成可直接照做的清单。以下步骤假设你已经装好了麒麟V10或者统信UOS系统并且有root或sudo权限。第一步安装依赖组件。录音服务依赖ffmpeg做音频转码sqlite做临时缓存以及Java运行时。执行系统包管理器安装时注意不要直接用编译版ffmpeg替换掉系统自带的版本否则可能跟系统安全组件的动态库冲突。第二步安装录音服务主程序。将安装包解压到/opt/recorder目录添加一个专用运行用户比如useradd -r -s /sbin/nologin recorder。千万不要用root直接跑录音服务一旦服务被利用攻击者就直接拥有整台服务器的权限了。第三步配置SIP监听地址。编辑conf/recorder.yaml设置本机监听IP为内网地址SIP端口默认5060。如果信令和媒体走不同网卡需要分别指定media_ip和sip_ip否则RTP包会走错路由导致录音只有单向声音。第四步配置话机侧。在每台IP话机上把SIP服务器地址指向录音服务器账号密码按照原有分机信息填写。如果话机所在网络与录音服务器跨网段记得在防火墙上放行UDP 5060和10000-20000端口段后者是RTP媒体端口范围。第五步启动并验证。systemctl start recorder然后再系统里拨打一通测试电话。看到日志出现[REC] START...到[REC] STOP...的记录并且去数据目录里检查是否有录音文件生成基本就说明流程跑通了。提示防火墙放行端口时一定要限制来源IP只允许话机所在网段访问录音服务器的SIP和RTP端口。否则就相当于把录音服务器的端口暴露在公网容易被第三方伪造SIP包发起骚扰注册。4.3 通话录音联调测试与验收清单上线前的联调测试不能只测“能不能录音”这一个点要按真实业务场景把状态机跑一遍。我们内部有一套验收用例覆盖了10个核心场景正常通话录音、主叫挂断、被叫挂断、呼叫转接、三方通话、呼叫保持恢复、通话中网络断开、免打扰拒接、定时录音策略、并发50路压力测试。每个用例的通过标准是录音文件能正常生成、时长与实际通话误差不超过3秒、文件可以被安全解密并播放、录音文件在数据库中有完整索引记录。这里特别说一下三方通话的测试不少方案在第三方加入时会把原通话的RTP流重协商录音模块如果没处理好会出现前半段正常、后半段突兀变成单侧声音的问题。我们发现处理办法是监听re-INVITE消息当发现SDP媒体协商发生变化时动态切换录音流上下文而不是重新创建新文件。并发测试同样重要。我们有次上线前做60路并发拨打测试发现录音服务转发延迟突然飙升到800毫秒追查后发现是录音模块的转码线程池默认只有4个线程大量AAC转码任务排队把CPU拖垮了。最终把线程池调整成CPU核心数的两倍延迟立刻降回150毫秒以内。这个参数在压测阶段必须提前调好否则上线当天用户一多服务就现形。5. 常见问题与排查技巧实录5.1 录音文件缺失或录音内容为空从哪里开始排查这个是最常见的工单原因种类多我按排查顺序整理成一张速查表。现象可能原因排查动作完全没生成录音文件话机未注册到录音服务器登录话机网页管理端查看SIP注册状态完全没生成录音文件SIP信令走了其他代理在录音服务器抓包分析SIP消息是否经过本机文件有大小但播放无声RTP端口没放行或协商异常确认10000-20000端口UDP是否放行文件有大小但播放无声话机开启了SRTP加密在话机上关闭媒体加密或开启录音服务SRTP解密只录到一半通话中被保持查看录音日志确认是否进入了保持暂停状态只录到一半网络闪断导致RTP中断确认通话期间网络质量看是否有丢包告警一个很隐蔽的坑是话机注册成功了但媒体流根本不经过录音服务器。这种情况通常是因为话机配置文件里媒体访问地址media address被设置成了话机直接获取到的内网地址而SIP服务器地址填的是录音服务器的域名。话机注册和呼叫信令走域名解析没有问题但RTP媒体协商时话机把媒体端点填成了自己的内网IP如果录音服务器和话机不在同一网段RTP包就直通了录音服务器永远拿不到媒体流。解决办法是把话机的媒体端口绑定到SIP服务器同网卡或者通过路由策略强制媒体流量经过录音服务器。5.2 国产话机兼容性差异如何把问题收敛到可控范围国产话机共享同一个大框架但细节实现差异很大。比如有的话机在收到200 OK时不会立即发送ACK确认而是等服务端再发一次确认才进入通话态如果录音服务器的SIP协议栈料得不够宽容就会判断通话未建立成功录音入口不开通。解决方案是给录音服务器的SIP状态机加一个“等待ACK超时重试”的容错分支超时时间设为话机注册时间的1.5倍。另外编解码器协商也是重灾区。我们遇到过某品牌话机默认只支持G.729而录音服务器只开G.711双方协商失败后话机直接回落到PCMU传输录音倒是能录但回放时音调异常。排查时看到录音文件的时长和通话时长对不上多半就是编解码不匹配导致的。建议开局时在所有话机上统一关闭不常用的编解码只保留G.711A/U和OPUS让媒体协商路径尽量简单。5.3 存储容量与长期运行的运维预警长期运行下来录音模块最大的运维压力就是磁盘和索引膨胀。我们上线三个月后某客户反馈系统查询变慢登录数据库一看录音索引表已经积累了近200万条记录单表查询超过3秒。处理方式是建立按月分表机制并对常用查询字段主叫号码、通话时间、分机号建立联合索引同时将超过180天的冷数据迁移到归档存储区主库只保留最近半年的索引。容量预警不能只盯着磁盘剩余百分比要看每日增长量。我习惯写一个定时脚本每天统计当天新增录音文件数和新增容量跟最近七天的均值做对比。如果某天增长量超过均值的三倍自动推送告警引起运维注意——这种异常往往意味着某个电话会议包被录得太过频繁或者某个分机被异常拨进拨出导致产生了大量通话记录。提前发现远比事后扩容有意义。最后分享一个我实际调录音时的小技巧如果你也正在排查话机注册成功但录音失败的老大难问题不妨先别急着抓RTP包先在录音服务器上执行一条简单的抓包命令过滤SIP信令消息看看provisional response和final response之间的间隔。我遇到过不少次问题根本不在录音软件本身而是话机固件在收到100 Trying之后迟迟不回180 Ringing导致录音服务判断振铃超时挂断会话最后生成一个几十字节的空文件。把话机固件升级到厂商推荐版本问题就消失了。录音方案这类系统级功能出了故障先怀疑最基础的协议交互往往比查高级功能模块更有效率。这就是我这次做信创IP话机录音方案最想分享的一句话。