接触呼叫中心业务的朋友都有体会一套完整的外呼链路往往不是靠单个系统硬撑起来的。线路资源、语音网关、号码路由、并发控制这些东西和坐席管理、客户资料、外呼任务、通话报表天然属于两个不同的管理层次。如果硬要把它们塞在一个系统里做配置会变得极其复杂出了问题也难以定位。VOS对接OKCC就是把这个链路拆开、再通过标准协议把两边高效连接起来。我这里说的VOS是承担软交换和网关职责的核心控制平台负责SIP接入、路由策略、线路分配和话单生成OKCC则偏向业务层负责坐席状态、外呼计划、客户资料和通话记录。两者对接完成后坐席在业务系统里发起呼叫信令和媒体流会经过VOS完成出局路由通话结束后的详细话单又能回到业务平台形成完整闭环。这篇教程会从方案选型讲起再到具体的SIP对接配置、路由设置、话单同步最后是常见故障排查适合正在准备上线呼叫中心、或者已经在运维中需要打通两套系统的开发、运维朋友参考。我尽量把每一步都掰碎了讲照着操作就能完成对接。1. 对接前先理清VOS和OKCC在呼叫链路中各管什么1.1 两个系统的角色划分我先拿一个比喻来说。VOS更像是“电话资源的调度中心”所有进出的语音通道、中继网关、号码池都由它统一管理。每当一通电话进来它要按照既定的策略决定从哪个线路出去按什么规则计费并发超过限制时该怎么处理。OKCC则是“业务运营前台”坐席登录、客户分配、外呼任务、通话留痕这些都在这里完成。它可以理解为把“业务想法”翻译成“一通通具体电话”的地方。对接时我习惯先把两边职责在纸上画清楚VOS提供SIP服务端/网关的接入能力OKCC是SIP客户端/中继的发起方VOS定义路由策略和放行规则OKCC定义呼叫目标和业务类型VOS产生原始话单OKCC把话单和客户、坐席、任务关联起来。只有当两边的边界清晰配置参数的时候才不会你等我、我等你最后互相推诿。1.2 对接要解决的三个核心问题我做了不少对接项目后把核心问题归纳成三条搞懂了这三点后面操作就顺了。第一呼叫如何发起。OKCC要拨打外线电话总得让VOS知道呼叫从哪里来、要往哪里去。最典型的做法是在VOS把OKCC描述为一个SIP中继或可信网关在OKCC把VOS配置为出局SIP代理这样OKCC发起呼叫时INVITE消息会直接送到VOS由VOS继续处理后续路由。第二路由如何匹配。VOS收到OKCC来的呼叫后不能无脑把所有电话都放到同一条线路上必须按被叫号码、主叫号码、时间段、费率组等因素选择最合适的出局路由。如果路由规则没设置好轻则电话打不出去重则走了高费率线路月底账单吓死人。第三状态和话单如何回流。业务平台不光要知道“电话有没有打通”还要知道“打了多久、费用多少、挂断原因是什么”。VOS在通话结束后生成的CDR通话详细记录必须同步到OKCCOKCC再把它关联到坐席和任务上。这一步经常被忽略但恰恰是运营最看重的部分。2. 对接方案选型SIP中继、API接口与数据库直连2.1 三种主流对接方案对比具体实施之前先选对接方式。我见过的项目里大致分为三种SIP中继对接OKCC作为SIP中继注册到VOS两边走标准的SIP协议呼叫和媒体都走IP网络。这是最通用、最推荐的方式配置量小、稳定性高、排障直观。API接口对接利用VOS提供的接口如开户、呼叫控制、话单查询由OKCC侧的业务代码去调用。适合需要深度定制比如要动态创建子账号、实时控制呼叫、回调通知的场景。数据库直连直接读取VOS的数据库表来拿话单或做配置。这种方式风险高数据库结构一变就崩而且容易产生锁竞争通常只建议在话单同步这种低频场景使用。两边对接要稳定我一般首选SIP中继必要的时候叠加API来做话单同步和控制。直接改数据库的做法能不上就不上。2.2 为什么SIP中继是首选SIP中继的优势在于“标准”。只要两边都支持标准SIP协议就基本没有兼容性问题抓包工具也能直接看到信令交互过程排障效率高。而且SIP中继天然支持多条并发呼叫带宽够的情况下扩容就是加并发数的事。相比API对接SIP中继不依赖业务代码的稳定性。哪怕OKCC侧因为版本升级暂时不可用VOS侧的呼叫处理也不受影响。API对接虽然灵活但要处理鉴权、错误重试、超时等一堆细节对开发团队要求更高。所以除非业务上有非常定制化的需求否则别想太多先把SIP中继打通再用API锦上添花。2.3 对接前需要准备的参数清单我开始操作前会先准备一张参数表避免配置到一半到处找信息VOS侧SIP监听IP和端口默认5060、SIP域/Realm、允许的中继IP或账号密码、路由策略所需的主叫/被叫规则、并发上限。OKCC侧SIP中继/网关的IP和端口、认证用户名和密码如果有、被叫号码的组网格式是否需要加前缀以及回传话单时VOS的对接地址或API密钥。网络侧两套系统之间的网络是否互通、是否需要放通UDP/TCP 5060端口、RTP媒体端口范围通常10000-20000是否可达。这些参数最好用表格维护好后面配置时直接对照填写。我这里贴一个示例项目VOS侧OKCC侧说明SIP地址192.168.1.10:5060192.168.1.20:5060内网互通即可认证方式IP白名单/账号密码对应账号推荐IP账号双验证主叫号码号码池/透传坐席外显号码两边保持一致RTP端口10000-2000010000-20000防火墙需放通3. 保姆级实操SIP中继对接全流程3.1 VOS侧创建SIP网关和中继第一次操作VOS时先登录管理后台找到“中继管理”或“SIP网关”相关菜单。我这里以通用流程说明不同版本的菜单位置会有差异但逻辑是相通的。创建中继的第一步是填写OKCC侧的IP地址和端口。比如OKCC的SIP地址是192.168.1.20端口5060就在VOS里新增一条SIP中继对端地址填192.168.1.20协议选UDP也有TCP看实际网络环境。如果VOS要求填写认证信息就把OKCC侧分配好的用户名和密码填进去。第二步是设置中继的权限。出于安全考虑我不建议把中继设置成“允许所有来源IP”这种宽泛策略最好指定只允许OKCC服务器的IP发起呼叫。否则公网上任意一个人猜到IP和端口都可能蹭你的线路打长途。第三步是设置并发上限。VOS里通常会有一个“最大并发呼叫数”的配置我的建议是先按实际业务量预估比如每坐席同时最多1通电话100坐席就填120留一点余量上线后再根据CPU、带宽情况调整。3.2 OKCC侧配置SIP账户与中继设置OKCC侧的配置思路正好相反它要把VOS当成出局代理。在OKCC的后台里找到“SIP中继”或“网关管理”新增一条中继目标地址填VOS的IP和端口也就是192.168.1.10:5060。如果VOS要求认证就在这里填VOS分配给OKCC的账号和密码。这里有一个容易踩坑的地方有些系统要求填写“主叫号码”或“外显号码”这时候千万别随意填要用VOS侧允许的号码池或线路支持的外显号码否则呼叫会被VOS拒绝。OKCC侧还有一类重要配置是“号码规范”。很多系统在拨号时会自动对号码做格式化比如把0去掉、把86转成0、补前缀等。对接前一定要和VOS的路由规则对好两边对号码的格式理解必须一致。我遇到过最头疼的问题就是两边都自作聪明地改号结果被叫到对端变成了完全不同的号码。配置完成后先在OKCC里测试注册。如果两边都支持注册模式在OKCC的中继状态里能看到“已注册”如果只是IP白名单模式的固定中继则没有注册状态只要网络通就默认可用。3.3 号码路由规则配置很多新手卡在这一步。先明确一个概念VOS收到OKCC送来的呼叫后它要知道把这通电话往哪个方向送。是送到某个运营商中继还是送到另一个落地网关还是走内部SIP线路这就需要配置路由策略。路由规则的逻辑通常是这样的当被叫号码匹配某个前缀条件时选择某个出局中继当主叫号码属于某个号码组时走指定的费率或线路。比如北上广深四个城市的号码分别走四个落地网关就可以配置四条前缀路由规则010走网关A、021走网关B、020走网关C、0755走网关D。配置时还要考虑优先级和默认路由。如果号码没匹配到任何规则是直接拒绝还是走默认线路我的建议是设置一条“兜底路由”宁可先走备用线路把呼叫送出去也比静默丢弃好但同时要打印日志方便追查哪些号码没有命中精确路由。在VOS里配置好路由策略后记得做一次最小化的路由测试先用一个测试被叫号码确认命中预期的中继再用几个不同前缀的号码验证规则边界。只有路由层完全符合预期再放量给坐席使用。3.4 呼叫测试与验证配置完成后不能直接上线先做完整的呼叫验证。我一般按以下顺序先测注册和鉴权。在OKCC侧查看中继状态是否为UP/已注册。如果注册失败优先查IP、端口、用户名、密码四要素再用抓包工具看SIP 401/403响应。再测基本呼叫。在OKCC里用一个测试坐席发起呼叫看VOS的呼叫日志确认INVITE已到VOS且匹配到了预期的路由。全程监听语音注意有没有单通、杂音、延迟。然后测媒体流。如果语音有问题抓包看RTP包是否双向通行。很多时候是防火墙只放通了UDP 5060漏了RTP端口段通常是10000-20000导致信令通了、语音却没有。最后测并发。同时发起几通测试呼叫确认VOS和OKCC的并发计数正确没有出现串线、资源耗尽的情况。并发测试建议在业务低峰期做否则影响了正常坐席就尴尬了。4. 话单对接让业务平台能对账4.1 话单字段对照呼叫通了话单也得通。VOS生成的通话记录里一般包含呼叫ID、主叫号码、被叫号码、开始时间、接通时间、结束时间、通话时长、挂断原因、费率、费用等字段。OKCC这边要做的是把这些字段关联到自己的业务对象上。我做一个字段对照表方便你规划对接字段VOS话单字段OKCC对应字段说明call_id通话唯一标识用于关联日志caller / ani主叫号码通常对应坐席外显calee / dnis被叫号码客户号码start_time呼叫开始时间时间戳格式ring_time振铃时间可计算未接answer_time接通时间判断是否接通end_time结束时间统计时长duration通话时长计费依据hangup_cause挂断原因用于未接通分类fee费用运营成本字段能对上后面的统计报表才做得了。我见过很多项目只同步了主被叫和时长没有同步挂断原因结果运营想分析“为什么这么多未接通”的时候完全没有数据支撑只能重新开发。4.2 话单同步的两种可行方式话单同步最常用两种方式一种是由OKCC主动调用VOS的API接口定时拉取增量话单另一种是VOS侧通过FTP/SFTP把话单文件推送到指定目录OKCC再解析入库。两种都可行区别主要在运维习惯上。用API拉取好处是实时性高OKCC可以每30秒或1分钟拉一次通话结束很快就能看到坏处是如果VOS的API鉴权严格或者接口有调用频率限制需要处理好重试和限流。用FTP推送好处是文件格式固定批量解析效率高适合话单量大的场景坏处是实时性差一些通常要等文件生成周期。我的经验是话单量每天在几万条以内的API拉取完全够用一天几十万上百万的优先考虑FTP推送配合定时任务做增量解析。不管用哪种方式一定要做对账任务每天比对两边的话单总数和总时长发现差异及时排查。5. 常见问题与排查技巧实录5.1 注册成功但呼叫失败先查路由再查号码注册成功只代表信令层面握手通过不代表呼叫一定能触达。如果你在OKCC发起的呼叫在VOS里能看到INVITE但后续被拒绝最常见的三个原因就是号码格式不符合路由规则、主叫号码不在VOS允许的号码池内、被叫号码没有命中出局路由。排查时先看VOS的系统日志找到那通被拒绝的呼叫里面会标明拒因。然后对应检查路由规则主叫是否在允许列表、被叫前缀是否命中规则、是否需要加或去前缀。这类问题通常都是配置和实际拨号格式不一致造成的。5.2 单通或没有回铃音问题多半在媒体流信令通了但语音没声十有八九是媒体流被防火墙拦截或者两边NAT配置不一致。SIP信令走的是5060端口媒体RTP则用动态端口段很多防火墙默认只放行了信令端口RTP包被丢弃就会出现“对方已经听到了但你这边一片安静”或者“能听到对方但对方听不到你”这种单通现象。解决方法是把VOS和OKCC之间的RTP端口范围互相放通并且保持两边SIP配置里的NAT模式一致。比如VOS侧开启NAT穿透OKCC侧也要把SIP的NAT选项打开否则信令里的IP地址和实际地址不一致媒体流就会发到错误的地方。5.3 通话被拒或无权呼叫核对鉴权和号码白名单如果VOS返回403/404等错误先看鉴权。SIP中继对接时如果两边约定了用户名密码务必确认OKCC侧发出的Authorization头里的账号和VOS中继里配置的账号完全一致。账号里多一个空格、大小写不对都会鉴权失败。另一个容易被忽略的是号码白名单。VOS侧通常会限制主叫号码只有白名单内的号码才能发起呼叫。有些系统支持正则表达式匹配比如^1[3-9]\d{9}$表示只允许11位手机号段。配置的时候别图省事写.*否则号码管理就失去了意义。5.4 话单对不上加一个每日对账任务话单数量对不上、时长对不上是运营上线后最头疼的问题。原因可能是API拉取漏了页、VOS话单生成有延迟、OKCC解析时字段类型转换出错。其中最隐蔽的是时区问题两边的服务器时区不同导致同一个呼叫的开始时间差了8小时看起来像丢了数据。所以部署时就要统一两边的服务器时区最好都用UTC8。同时做一个每日对账脚本比较VOS和OKCC的话单总数、总通话时长、总费用差异超过阈值就告警。5.5 并发高了就掉卡关注带宽和许可还有一种常见情况业务量上来后呼叫质量明显下降甚至出现掉卡。这时候先排查是不是并发许可满了。VOS侧的并发许可、OKCC侧的坐席并发任何一个达到上限新呼叫都会失败。两者要整体规划不能VOS开到500并发OKCC只买了200坐席白白浪费线路资源。另外就是带宽。语音按G.711编码算一路通话大约需要80-100kbps带宽100路并发至少要有10Mbps的稳定上行带宽。带宽不够时先出现的就是杂音、延迟、掉包。这个计算公式可以在上线前做容量规划时直接用别等出问题了才想起来。最后再分享一个我自己的习惯。每次做完对接我一定会在VOS和OKCC两侧各留一份完整的配置截图和参数清单存到同一个共享目录里。这样后续不管谁接手都能在半小时内把环境还原清楚。对接这件事难度其实不大难的是每一步都保持冷静、按顺序验证。先把网络通再配信令再调路由再验话单一步一步来成功率会高很多。
接触呼叫中心业务的朋友都有体会一套完整的外呼链路往往不是靠单个系统硬撑起来的。线路资源、语音网关、号码路由、并发控制这些东西和坐席管理、客户资料、外呼任务、通话报表天然属于两个不同的管理层次。如果硬要把它们塞在一个系统里做配置会变得极其复杂出了问题也难以定位。VOS对接OKCC就是把这个链路拆开、再通过标准协议把两边高效连接起来。我这里说的VOS是承担软交换和网关职责的核心控制平台负责SIP接入、路由策略、线路分配和话单生成OKCC则偏向业务层负责坐席状态、外呼计划、客户资料和通话记录。两者对接完成后坐席在业务系统里发起呼叫信令和媒体流会经过VOS完成出局路由通话结束后的详细话单又能回到业务平台形成完整闭环。这篇教程会从方案选型讲起再到具体的SIP对接配置、路由设置、话单同步最后是常见故障排查适合正在准备上线呼叫中心、或者已经在运维中需要打通两套系统的开发、运维朋友参考。我尽量把每一步都掰碎了讲照着操作就能完成对接。1. 对接前先理清VOS和OKCC在呼叫链路中各管什么1.1 两个系统的角色划分我先拿一个比喻来说。VOS更像是“电话资源的调度中心”所有进出的语音通道、中继网关、号码池都由它统一管理。每当一通电话进来它要按照既定的策略决定从哪个线路出去按什么规则计费并发超过限制时该怎么处理。OKCC则是“业务运营前台”坐席登录、客户分配、外呼任务、通话留痕这些都在这里完成。它可以理解为把“业务想法”翻译成“一通通具体电话”的地方。对接时我习惯先把两边职责在纸上画清楚VOS提供SIP服务端/网关的接入能力OKCC是SIP客户端/中继的发起方VOS定义路由策略和放行规则OKCC定义呼叫目标和业务类型VOS产生原始话单OKCC把话单和客户、坐席、任务关联起来。只有当两边的边界清晰配置参数的时候才不会你等我、我等你最后互相推诿。1.2 对接要解决的三个核心问题我做了不少对接项目后把核心问题归纳成三条搞懂了这三点后面操作就顺了。第一呼叫如何发起。OKCC要拨打外线电话总得让VOS知道呼叫从哪里来、要往哪里去。最典型的做法是在VOS把OKCC描述为一个SIP中继或可信网关在OKCC把VOS配置为出局SIP代理这样OKCC发起呼叫时INVITE消息会直接送到VOS由VOS继续处理后续路由。第二路由如何匹配。VOS收到OKCC来的呼叫后不能无脑把所有电话都放到同一条线路上必须按被叫号码、主叫号码、时间段、费率组等因素选择最合适的出局路由。如果路由规则没设置好轻则电话打不出去重则走了高费率线路月底账单吓死人。第三状态和话单如何回流。业务平台不光要知道“电话有没有打通”还要知道“打了多久、费用多少、挂断原因是什么”。VOS在通话结束后生成的CDR通话详细记录必须同步到OKCCOKCC再把它关联到坐席和任务上。这一步经常被忽略但恰恰是运营最看重的部分。2. 对接方案选型SIP中继、API接口与数据库直连2.1 三种主流对接方案对比具体实施之前先选对接方式。我见过的项目里大致分为三种SIP中继对接OKCC作为SIP中继注册到VOS两边走标准的SIP协议呼叫和媒体都走IP网络。这是最通用、最推荐的方式配置量小、稳定性高、排障直观。API接口对接利用VOS提供的接口如开户、呼叫控制、话单查询由OKCC侧的业务代码去调用。适合需要深度定制比如要动态创建子账号、实时控制呼叫、回调通知的场景。数据库直连直接读取VOS的数据库表来拿话单或做配置。这种方式风险高数据库结构一变就崩而且容易产生锁竞争通常只建议在话单同步这种低频场景使用。两边对接要稳定我一般首选SIP中继必要的时候叠加API来做话单同步和控制。直接改数据库的做法能不上就不上。2.2 为什么SIP中继是首选SIP中继的优势在于“标准”。只要两边都支持标准SIP协议就基本没有兼容性问题抓包工具也能直接看到信令交互过程排障效率高。而且SIP中继天然支持多条并发呼叫带宽够的情况下扩容就是加并发数的事。相比API对接SIP中继不依赖业务代码的稳定性。哪怕OKCC侧因为版本升级暂时不可用VOS侧的呼叫处理也不受影响。API对接虽然灵活但要处理鉴权、错误重试、超时等一堆细节对开发团队要求更高。所以除非业务上有非常定制化的需求否则别想太多先把SIP中继打通再用API锦上添花。2.3 对接前需要准备的参数清单我开始操作前会先准备一张参数表避免配置到一半到处找信息VOS侧SIP监听IP和端口默认5060、SIP域/Realm、允许的中继IP或账号密码、路由策略所需的主叫/被叫规则、并发上限。OKCC侧SIP中继/网关的IP和端口、认证用户名和密码如果有、被叫号码的组网格式是否需要加前缀以及回传话单时VOS的对接地址或API密钥。网络侧两套系统之间的网络是否互通、是否需要放通UDP/TCP 5060端口、RTP媒体端口范围通常10000-20000是否可达。这些参数最好用表格维护好后面配置时直接对照填写。我这里贴一个示例项目VOS侧OKCC侧说明SIP地址192.168.1.10:5060192.168.1.20:5060内网互通即可认证方式IP白名单/账号密码对应账号推荐IP账号双验证主叫号码号码池/透传坐席外显号码两边保持一致RTP端口10000-2000010000-20000防火墙需放通3. 保姆级实操SIP中继对接全流程3.1 VOS侧创建SIP网关和中继第一次操作VOS时先登录管理后台找到“中继管理”或“SIP网关”相关菜单。我这里以通用流程说明不同版本的菜单位置会有差异但逻辑是相通的。创建中继的第一步是填写OKCC侧的IP地址和端口。比如OKCC的SIP地址是192.168.1.20端口5060就在VOS里新增一条SIP中继对端地址填192.168.1.20协议选UDP也有TCP看实际网络环境。如果VOS要求填写认证信息就把OKCC侧分配好的用户名和密码填进去。第二步是设置中继的权限。出于安全考虑我不建议把中继设置成“允许所有来源IP”这种宽泛策略最好指定只允许OKCC服务器的IP发起呼叫。否则公网上任意一个人猜到IP和端口都可能蹭你的线路打长途。第三步是设置并发上限。VOS里通常会有一个“最大并发呼叫数”的配置我的建议是先按实际业务量预估比如每坐席同时最多1通电话100坐席就填120留一点余量上线后再根据CPU、带宽情况调整。3.2 OKCC侧配置SIP账户与中继设置OKCC侧的配置思路正好相反它要把VOS当成出局代理。在OKCC的后台里找到“SIP中继”或“网关管理”新增一条中继目标地址填VOS的IP和端口也就是192.168.1.10:5060。如果VOS要求认证就在这里填VOS分配给OKCC的账号和密码。这里有一个容易踩坑的地方有些系统要求填写“主叫号码”或“外显号码”这时候千万别随意填要用VOS侧允许的号码池或线路支持的外显号码否则呼叫会被VOS拒绝。OKCC侧还有一类重要配置是“号码规范”。很多系统在拨号时会自动对号码做格式化比如把0去掉、把86转成0、补前缀等。对接前一定要和VOS的路由规则对好两边对号码的格式理解必须一致。我遇到过最头疼的问题就是两边都自作聪明地改号结果被叫到对端变成了完全不同的号码。配置完成后先在OKCC里测试注册。如果两边都支持注册模式在OKCC的中继状态里能看到“已注册”如果只是IP白名单模式的固定中继则没有注册状态只要网络通就默认可用。3.3 号码路由规则配置很多新手卡在这一步。先明确一个概念VOS收到OKCC送来的呼叫后它要知道把这通电话往哪个方向送。是送到某个运营商中继还是送到另一个落地网关还是走内部SIP线路这就需要配置路由策略。路由规则的逻辑通常是这样的当被叫号码匹配某个前缀条件时选择某个出局中继当主叫号码属于某个号码组时走指定的费率或线路。比如北上广深四个城市的号码分别走四个落地网关就可以配置四条前缀路由规则010走网关A、021走网关B、020走网关C、0755走网关D。配置时还要考虑优先级和默认路由。如果号码没匹配到任何规则是直接拒绝还是走默认线路我的建议是设置一条“兜底路由”宁可先走备用线路把呼叫送出去也比静默丢弃好但同时要打印日志方便追查哪些号码没有命中精确路由。在VOS里配置好路由策略后记得做一次最小化的路由测试先用一个测试被叫号码确认命中预期的中继再用几个不同前缀的号码验证规则边界。只有路由层完全符合预期再放量给坐席使用。3.4 呼叫测试与验证配置完成后不能直接上线先做完整的呼叫验证。我一般按以下顺序先测注册和鉴权。在OKCC侧查看中继状态是否为UP/已注册。如果注册失败优先查IP、端口、用户名、密码四要素再用抓包工具看SIP 401/403响应。再测基本呼叫。在OKCC里用一个测试坐席发起呼叫看VOS的呼叫日志确认INVITE已到VOS且匹配到了预期的路由。全程监听语音注意有没有单通、杂音、延迟。然后测媒体流。如果语音有问题抓包看RTP包是否双向通行。很多时候是防火墙只放通了UDP 5060漏了RTP端口段通常是10000-20000导致信令通了、语音却没有。最后测并发。同时发起几通测试呼叫确认VOS和OKCC的并发计数正确没有出现串线、资源耗尽的情况。并发测试建议在业务低峰期做否则影响了正常坐席就尴尬了。4. 话单对接让业务平台能对账4.1 话单字段对照呼叫通了话单也得通。VOS生成的通话记录里一般包含呼叫ID、主叫号码、被叫号码、开始时间、接通时间、结束时间、通话时长、挂断原因、费率、费用等字段。OKCC这边要做的是把这些字段关联到自己的业务对象上。我做一个字段对照表方便你规划对接字段VOS话单字段OKCC对应字段说明call_id通话唯一标识用于关联日志caller / ani主叫号码通常对应坐席外显calee / dnis被叫号码客户号码start_time呼叫开始时间时间戳格式ring_time振铃时间可计算未接answer_time接通时间判断是否接通end_time结束时间统计时长duration通话时长计费依据hangup_cause挂断原因用于未接通分类fee费用运营成本字段能对上后面的统计报表才做得了。我见过很多项目只同步了主被叫和时长没有同步挂断原因结果运营想分析“为什么这么多未接通”的时候完全没有数据支撑只能重新开发。4.2 话单同步的两种可行方式话单同步最常用两种方式一种是由OKCC主动调用VOS的API接口定时拉取增量话单另一种是VOS侧通过FTP/SFTP把话单文件推送到指定目录OKCC再解析入库。两种都可行区别主要在运维习惯上。用API拉取好处是实时性高OKCC可以每30秒或1分钟拉一次通话结束很快就能看到坏处是如果VOS的API鉴权严格或者接口有调用频率限制需要处理好重试和限流。用FTP推送好处是文件格式固定批量解析效率高适合话单量大的场景坏处是实时性差一些通常要等文件生成周期。我的经验是话单量每天在几万条以内的API拉取完全够用一天几十万上百万的优先考虑FTP推送配合定时任务做增量解析。不管用哪种方式一定要做对账任务每天比对两边的话单总数和总时长发现差异及时排查。5. 常见问题与排查技巧实录5.1 注册成功但呼叫失败先查路由再查号码注册成功只代表信令层面握手通过不代表呼叫一定能触达。如果你在OKCC发起的呼叫在VOS里能看到INVITE但后续被拒绝最常见的三个原因就是号码格式不符合路由规则、主叫号码不在VOS允许的号码池内、被叫号码没有命中出局路由。排查时先看VOS的系统日志找到那通被拒绝的呼叫里面会标明拒因。然后对应检查路由规则主叫是否在允许列表、被叫前缀是否命中规则、是否需要加或去前缀。这类问题通常都是配置和实际拨号格式不一致造成的。5.2 单通或没有回铃音问题多半在媒体流信令通了但语音没声十有八九是媒体流被防火墙拦截或者两边NAT配置不一致。SIP信令走的是5060端口媒体RTP则用动态端口段很多防火墙默认只放行了信令端口RTP包被丢弃就会出现“对方已经听到了但你这边一片安静”或者“能听到对方但对方听不到你”这种单通现象。解决方法是把VOS和OKCC之间的RTP端口范围互相放通并且保持两边SIP配置里的NAT模式一致。比如VOS侧开启NAT穿透OKCC侧也要把SIP的NAT选项打开否则信令里的IP地址和实际地址不一致媒体流就会发到错误的地方。5.3 通话被拒或无权呼叫核对鉴权和号码白名单如果VOS返回403/404等错误先看鉴权。SIP中继对接时如果两边约定了用户名密码务必确认OKCC侧发出的Authorization头里的账号和VOS中继里配置的账号完全一致。账号里多一个空格、大小写不对都会鉴权失败。另一个容易被忽略的是号码白名单。VOS侧通常会限制主叫号码只有白名单内的号码才能发起呼叫。有些系统支持正则表达式匹配比如^1[3-9]\d{9}$表示只允许11位手机号段。配置的时候别图省事写.*否则号码管理就失去了意义。5.4 话单对不上加一个每日对账任务话单数量对不上、时长对不上是运营上线后最头疼的问题。原因可能是API拉取漏了页、VOS话单生成有延迟、OKCC解析时字段类型转换出错。其中最隐蔽的是时区问题两边的服务器时区不同导致同一个呼叫的开始时间差了8小时看起来像丢了数据。所以部署时就要统一两边的服务器时区最好都用UTC8。同时做一个每日对账脚本比较VOS和OKCC的话单总数、总通话时长、总费用差异超过阈值就告警。5.5 并发高了就掉卡关注带宽和许可还有一种常见情况业务量上来后呼叫质量明显下降甚至出现掉卡。这时候先排查是不是并发许可满了。VOS侧的并发许可、OKCC侧的坐席并发任何一个达到上限新呼叫都会失败。两者要整体规划不能VOS开到500并发OKCC只买了200坐席白白浪费线路资源。另外就是带宽。语音按G.711编码算一路通话大约需要80-100kbps带宽100路并发至少要有10Mbps的稳定上行带宽。带宽不够时先出现的就是杂音、延迟、掉包。这个计算公式可以在上线前做容量规划时直接用别等出问题了才想起来。最后再分享一个我自己的习惯。每次做完对接我一定会在VOS和OKCC两侧各留一份完整的配置截图和参数清单存到同一个共享目录里。这样后续不管谁接手都能在半小时内把环境还原清楚。对接这件事难度其实不大难的是每一步都保持冷静、按顺序验证。先把网络通再配信令再调路由再验话单一步一步来成功率会高很多。
