简介《VOS3000操作手册》面向虚拟运营支撑系统客户端的使用者、运营维护人员及计费管理人员帮助其熟悉系统界面、业务配置与日常维护流程。正文先说明手册使用方式再按功能展开系统登录、费率组与费率规则、套餐组及赠送时长和时段费率、普通账户与代理账户、账户缴费与计费、呼叫跟踪以及网关和话机业务等模块配有图示和实例便于对照界面完成配置与核查。压缩包仅含1个doc文档约10.02MB按章节和目录组织适合按模块检索或通读学习。目前已有1112人学习可作为掌握VOS3000费率、套餐、账户计费和业务管理操作的随查手册对费率组、套餐时段费率、代理账户计费、账户权限与号码段限制等易混设置也能结合章节说明逐项核对尤其适合初、中级使用者查漏补缺。1. 那份出事才会被翻开的 VOS3000 操作手册到底该怎么读接手一套跑了两年以上的软交换平台最先拿到手的往往不是拓扑图而是一本《VOS3000 操作手册》。我第一次认真翻它是在凌晨两点某条线路的结算金额比预估高出三倍查到最后不是线路故障也不是网关掉包而是费率表里同时躺着0和00两个前缀最长匹配把本该走国际价的呼叫吃进了国内长途。这种事故不会触发任何监控告警只会在月底的对账单上冒出来。这本手册覆盖面比想象中窄也比想象中深窄在它只讲客户端怎么点、字段怎么填深在它把费率、套餐、账户、网关、话单分析这五条主线全部串成了一套数据字典。它适合三类人——刚接手平台、要在一周内独立完成费率上架的运维每天出话费报表、需要把差异解释清楚的计费岗以及被代理追着问“这个号为什么打不出去”的支撑岗。按费率、账户、业务、话单的顺序通读一遍比把它当字典随手查要省事得多。2. 费率与套餐的计费模型把“一分钟多少钱”拆成四层可验算的结构计费出错的地方九成不在系统在配置的表达方式上。一个人说“这条线路一分钟两毛”他脑子里的模型是一维的而 VOS3000 客户端里的模型是四维的费率组、费率条目、前缀匹配规则、套餐叠加。四个维度里任何一个填歪账面上的数字都会以倍数级别偏出去。这一章把这四层拆开每层给出可手算复核的方法。2.1 费率组、费率条目、前缀三层结构各自管什么费率组是一个容器它的名字会直接出现在账户创建时的下拉框里所以命名必须自带信息量。见过太多平台里躺着test、默认、新建费率组1这样的名字等到三个月后要改价没人知道哪个组在跑生产。合格的做法是把运营商、方向、币种、生效月份塞进名字例如A方向-国际-人民币-2024Q3长度不敏感可读性优先。费率组这一层有三个容易被忽略的字段。费率数量是组内实际条目数双击这个数字能直接钻进条目管理页比右键菜单快。电话卡60秒等效时长决定卡类用户 IVR 播报可通话时长时怎么折算填错的表现是卡用户听到的“还能打 X 分钟”和实际扣费对不上。使用账户数是删除前的安全阀——一个组还挂着账户时不要动它双击这个数字能看到是哪些账户在引用。费率条目层才是真正决定价格的地方字段包括费率前缀、地区前缀、费率类型、分段费率、计费费率、计费周期、锁定类型。这里有一个隐性约束费率类型网内、本地、国内长途、国际长途不只是话单上的一个标签它同时参与话机呼叫权限校验。话机没开通对应级别呼叫会被直接拒绝而很多人在排查“能注册但打不出去”时第一反应是查网关最后才发现是费率类型选错导致权限校验没过。地区前缀的显示依赖《号码管理 → 地区信息》里的记录。如果地区信息表是空的地区名称栏就一片空白不影响计费但报表里的地区分析会全部堆到“未知”后面想做地区维度的话务分布就没有数据基础。上费率之前先把地区信息补一遍是个成本很低的前置动作。2.2 费率前缀的最长匹配0 和 00 为什么不能随性子共存手册里写得很清楚费率前缀匹配按最长匹配原则。存在0与01两条费率时拨打01117会命中01。这句话反过来读才是关键——如果费率表里只有0而没有00那么拨打0086...这类号码时最长匹配只能落到0于是国际长途被按国内长途计价。这就是我开头说的那次事故的完整成因。当时对方的费率表是这么建的国内长途只设了一条0国际长途零零散散录了十几条00xxx但00这个总前缀没建。结果所有打往没有单独录入的国家和地区的呼叫全部降级到0计费。系统没有任何异常因为从匹配规则看它完全正确。正确的建法是手册里给的忠告国内长途用01到09多条费率表示不要单独设一个0兜底。这样00开头的呼叫只会匹配00前缀的国际费率匹配不到就按无费率处理通常是拒绝或走默认而不是静默地按国内价跑。宁可让它打不通也不要让它打得太便宜——前者是故障会被投诉后者是漏洞要等到对账才发现。费率表写法拨打 01117拨打 0086138xxxx风险只有0、01命中01命中0按国内价国际长途被低价计费静默亏损0、01~09、00命中01命中00结构清晰推荐只有01~09、00命中01命中00无兜底异常号码直接拒绝0、01、00混建命中01命中00可接受但0仍可能兜住其他前缀建完后一定要做一轮“反向验证”把费率表导出按前缀长度排序人工扫一遍有没有“短前缀覆盖了本该由长前缀处理的号段”。手工扫一遍十分钟比月底对账三天划算。2.3 分段费率与计费周期三个算例把公式钉死这是整套计费里最容易想当然的部分。手册给的定义是先走分段费率通话超出分段总时长后按计费周期与计费费率计算分段费率为空时直接按计费周期与计费费率算。计费周期不足整数倍时向上取整多算一个周期。手册自带算例首次费率0.21、首次时长180秒、计费费率0.15、计费周期60秒通话 250 秒费用 0.21 0.15 × 2 0.51元。为什么是 2 个周期因为 250 − 180 70 秒70 ÷ 60 1.17向上取整得 2。光记这一个例子不够边界才是翻车现场。我按同一套参数把几个临界点算了一遍通话时长秒超出首次时长周期数向上取整费用元备注179000.21未超首次时长只收首次费180000.21恰好等于首次时长不加周期181110.36多 1 秒也吃满一个周期2406010.36整周期边界2416120.51多 1 秒再吃一个周期2507020.51手册算例表中的181和241这两行是最容易吵架的地方。客户侧看到“我只多打了 1 秒”账单上却多了一个完整周期情绪上很难接受。这不是系统抠门是计费周期定义决定的配置前必须跟业务方确认口径别等出账了再解释。分段费率本身是带序号的多行结构可以配成阶梯前 60 秒一个价、60 到 180 秒另一个价、之后按周期。实际配置时序号必须连续且时长累加合理中间留空会导致超出部分直接跳到周期计费逻辑行为跟预期不同。改完阶梯之后务必用上表的方法自己算三行别信“应该没问题”。2.4 套餐的扣减顺序赠送时长、赠送金额、租金谁先动套餐是在费率之上叠加的一层优惠。它的字段看着简单——租用周期、租用单位、租用类型、租用租金、时段费率、赠送时长——但扣减顺序决定了月底账目能不能对上。租金按日、月、年三种类型在“每个时段的开始时刻”扣费。如果账户同时挂着多个套餐扣费顺序是日租、月租、年租依次进行。关键在于后半句某个套餐的租金余额不足时系统视为该账户没有这个套餐。也就是说钱不够不是欠费是直接失效。这个设计很干脆但运营侧要提前告知客户否则会出现“明明套餐还在有效期怎么就按标准费率计费了”的投诉。赠送部分的优先级是先赠送时长再赠送金额。这个顺序对客户是划算的——时长先消耗意味着超出套餐的分钟数往后推而金额留到最后兜底。做套餐对比表的时候这个顺序会显著影响“哪个套餐更值”的结论不能只看总面值。时段费率挂在套餐上通过右键打开时段费率组管理可以按时间段设不同价格。典型场景是周末两天走0.05、晚间 23 点到次日 8 点走0.3。配置时的坑在于时间段重叠两个时段都覆盖 23:00 到 24:00 时谁生效取决于内部顺序而不是你填的先后所以配完必须用实际呼叫打几通验证挑一个跨时段的时刻比如 22:58 拨出、23:02 挂断看话单落在哪个时段、按哪个费率结算。费率组和套餐都支持权限属性代理商登录后只能看到自己访问用户列表里的条目。这套隔离机制的边界是只隔离可见性不隔离计费逻辑。也就是说代理商看不到某个费率组但归属于他的账户如果绑定了这个组呼叫仍然按该组计费。做代理配置时账户绑定关系要单独核一遍不能只看权限列表。3. 账户体系与建号流程从费率组到号码段限制的配置链条3.1 普通账户、代理账户、权限管理三者的关系系统里的账户分两类普通账户和代理账户。普通账户是计费主体持有余额、绑定费率组、挂套餐、产生话单代理账户是管理主体本身不直接承担话务计费但可以创建和管理下级账户并从中获取分成。这两者容易混的地方在于“权限管理”这个功能同时出现在两个位置。费率组的权限属性、套餐的权限管理控制的是“哪些登录用户能看到这个资源”账户的权限管理控制的是“这个账户能用哪些资源、能操作哪些功能”。前者是可见性后者是能力边界。排查“代理商看不到费率”时查前者排查“代理商改不了下级账户”时查后者。代理账户还有一个独有字段访问用户。它决定了代理商登录后能看到哪些资源条目。手册明确提到代理商 Everyone 不可修改某些费率。这背后的设计意图是系统预置的公共资源对所有代理可见但不可改代理自建资源才能编辑。理解了这一点就不会在“为什么这个按钮是灰的”上浪费半天。3.2 建账户的标准顺序五步不要跳我习惯把开户拆成固定五步跳步的后果通常在第一次呼叫或第一次出账时爆发。第一步确认费率组已就绪。新建账户的下拉框只列出有权限的费率组如果下拉是空的先回去查费率组权限不要在账户页面反复试。第二步确认套餐是否必需。不需要套餐就直接跳过需要的话确认套餐的租用类型与租金因为套餐绑定后第一次扣费就在时段开始时刻开户当天可能立刻扣一笔客户会问。第三步建账户填账户名、密码、费率组、初始余额。账户名建议带业务含义跟费率组命名一个逻辑。第四步配号码段限制和主被叫名单。这一步是准入控制不做的话账户能打全网。第五步做一笔真实呼叫验证看话单里的费率组、费率前缀、计费金额三项是否与预期一致。第五步经常被省掉。省掉它的团队问题会在批量开户之后集中爆发——几十个账户一起错改起来就是几十次重复操作。3.3 账户计费与余额扣减的边界账户的计费这个功能模块的名字容易误导它不是“设置计费规则”而是把费率、套餐、余额三者在账户维度的实际计算结果呈现出来。理解这一点的标志是你能解释清楚为什么这个账户这一通电话扣了这么多钱。扣减的完整链路是先判断套餐是否有赠送时长有就扣时长时长耗尽后判断是否有赠送金额有就扣金额都没有则走账户余额。余额不足时的行为取决于系统参数配置可能是允许透支到某个额度也可能是直接中断呼叫。这里的参数属于《操作补充说明 → 系统参数》的范畴改之前务必记录原值因为它的影响面是全平台而不是单个账户。有一个隐蔽的坑账户同时绑多个套餐时扣租顺序是日、月、年。如果日租套餐的租金扣不掉系统视为没有这个套餐那么这个套餐的时段费率和赠送时长同时失效账户直接跳回基础费率组计价。表现是“同一个客户昨天还是优惠价今天突然变成标准价”而余额看起来还有钱——因为钱够扣月租不够扣日租。这种账目差异靠肉眼很难发现得靠报表对比。3.4 号码段限制与主被叫名单准入控制的两道闸账户号码段限制控制账户能拨哪些号段主叫名单和被叫名单控制具体的黑白名单。前者是粗粒度后者是细粒度两者是“与”的关系号段允许但被叫名单禁止照样打不通。配置顺序上先做号段限制再做名单因为号段的批量操作效率高。号段限制的常见误用是“只加允许的忘了默认行为”——不同参数配置下未列出的号段可能是全禁也可能是全通改之前先在测试账户上验证一次默认行为比查文档快。主叫名单的用途之一是防漫游滥用某个账户的号码只允许从特定主叫发起呼叫。被叫名单则常用于临时封禁高风险目的地。这两个名单都支持导入导出批量维护时用导出模板改完再导回比在界面里一行行点可靠。导入前建议先导出当前数据留底这是我踩过一次坑之后养成的习惯——一次误导入把原有名单全覆盖了恢复花了两个小时。4. 业务管理网关与话机的参数填写与四张分析表串查4.1 网关业务与话机业务的本质差别网关业务和话机业务在界面上长得像逻辑完全不同。网关对应的是中继对接一端是运营商或上游线路通常按 IP 或对接认证方式建立关心的是并发路数、号码变换、路由策略。话机对应的是终端注册关心的是注册状态、心跳、NAT 穿透。判断自己该配哪个看对端设备如果对端是一台提供 SIP 中继的设备或线路配网关如果对端是话机、软电话、IPPBX 下的分机配话机。配错的表现是“配置看起来都填了但注册不上”因为协议路径根本不同。网关业务页面通常还涉及费率绑定——网关进来或出去的话务按哪个费率组计费。这个绑定关系错配是话单金额异常的第二大来源第一大是前缀匹配。绑定后建议立刻打一通测试电话在话单里确认费率组名称。4.2 上线顺序域名、软交换、网关、绑定一条新线路从零到能打电话顺序建议固定为域名管理 → 软交换管理 → 网关或话机 → 费率与账户绑定。域名管理排第一是因为很多对接参数里要填域名或主机标识先有域名再填参数能避免后面反复改。软交换管理是核心它承载了注册端口、媒体相关开关、心跳与超时等平台级参数。这一层的参数改动影响全平台属于“改之前要备份、改之后要观察”的级别。手册在《操作补充说明 → 参数说明》里对软交换参数和 IVR 参数有专门篇幅实际动手前对照着看一遍能少走很多弯路。网关业务和话机业务的配置项里最容易被忽略的是与号码变换相关的字段。号码变换决定送出局的主叫被叫格式格式不对的表现是对端直接回错误码而且错误码往往很含糊看起来像认证问题。常见做法是先用最朴素的配置打通跑通后再加变换规则一次只加一条规则加完立刻验证别攒着一起改。服务器维护这一层的手册内容很薄只讲了服务的启动、关闭、重启。实际运维中这三件事的通用做法是用系统服务管理命令而不是在客户端里点# 查看软交换相关进程是否在跑先确认服务名再操作 ps -ef | grep -i 服务名 | grep -v grep # 优雅重启先停再起中间确认端口已释放 systemctl stop 服务名 sleep 3 ss -lntp | grep 端口号 # 确认端口没被残留进程占着 systemctl start 服务名 # 起完立刻看日志尾部别等用户报障 tail -n 200 日志路径这几条命令的逻辑说明ps那一步是为了确认服务名不同部署方式下名字不一样别照抄sleep 3是给端口释放留时间紧接着ss检查端口能挡住“重启后起不来但没报错”的情况tail是给自己留后悔药服务起来了不代表业务正常日志里通常有关键线索。参数上唯一要改的就是三个占位符服务名、端口号、日志路径按实际部署替换。4.3 注册分析、呼叫分析、当前通话、通话性能怎么串起来看这四张表是排障的主战场很多人只会看其中一张导致结论偏差。当前通话是实时快照看得见正在通话的数量、时长、主被叫、走的网关。它的价值在于“现在就能确认业务是否在跑”新线路配完先看这里有没有流量比打电话快。通话性能是统计视角看接通率、平均通话时长、失败分布。它的价值在于判断问题是全局还是局部。接通率整体掉怀疑平台层只有某条线路掉怀疑对接层。呼叫分析是单通级别能看到具体某一通呼叫经过了哪些环节、在哪一步失败。它的价值在于定位。配合通话终止原因那张表手册在补充说明里给了服务器侧原因和 VoIP 设备侧原因两大类能快速缩小范围服务器侧原因多半是配置或资源问题设备侧原因多半是对接或网络问题。注册分析只看注册不看呼叫。话机掉线、网关状态异常先看这张表。它的典型用途是区分“注册失败”和“注册成功但呼叫失败”——这两种现象的处理路径完全不同混在一起排查会浪费大量时间。串查的固定动作是先看注册分析确认在线再看当前通话确认有流量出问题看呼叫分析定位单通最后用通话性能判断影响面。4.4 通话终止原因的判读逻辑手册给出的终止原因分两大类服务器原因和 VoIP 设备产生原因。实操中的判读原则是服务器原因优先查配置和资源费率没匹配、账户余额不足、号码被名单拦截、并发打满设备原因优先查对接对端拒绝、认证失败、媒体协商失败、超时。一个反直觉的点大量“设备原因”最终追到平台侧配置。比如对端回认证失败往往是因为本地送出的认证字段与对端预期不一致属于本地配置问题。所以看到设备侧原因不要立刻甩锅给上游先把本地的认证、号码格式、编码协商三项核对一遍再联系对方。5. 踩坑排查五类把账算错、把呼叫卡死的现场5.1 现象费率改完话单金额纹丝不动现象改了某条费率的前缀和价格界面上显示已更新打了几通测试电话话单金额还是老价格。原因VOS3000 客户端绝大多数表格采用“本地编辑 应用生效”的模式。增、删、改只在客户端缓存里没点应用就关掉页面等同于放弃修改。手册在功能操作指南开头就用加粗提示过这一点但几乎所有人都是一次踩坑后才记住。解决养成“改完必点应用、点完必重开页面”的动作。重开页面的目的是强制从服务器拉一次数据如果重开后改动还在说明真的落库了。另外多人同时操作同一张表时后应用的人可能覆盖前一个人的改动改费率这种低频高风险操作最好约定同一时间只有一个人动。5.2 现象国际长途被按国内价结算账面上看不出来现象月底对账发现某方向收入异常偏低倒查话单发现一批打往境外的呼叫按国内长途价格结算。原因费率表里国内长途用单条0前缀兜底而国际费率只录了部分00xxx前缀未录入的国家和地区在最长匹配下落到0。系统行为完全正确错的是费率表结构。解决国内长途拆成01到09多条不设单一0兜底国际统一建00总前缀再按国家细化00xxx。改完按 2.2 节的表格做反向验证把导出的费率表按前缀长度排序人工扫一遍。这一步我叫它“后悔药流程”做一次二十分钟能挡住一整个季度的静默亏损。5.3 现象导入外部费率表之后前缀全乱现象从上游拿到一张费率表导入后拨打测试号码匹配到的前缀跟预期完全不符有的号码甚至匹配到了八竿子打不着的地区。原因外部费率表格式不规范前缀位数不统一有的带前导零有的不带有的把国家码和地区码挤在一列。导入只是把行灌进去不会帮你补零或拆列。解决导入后用右键菜单里的“增加前缀起始位”和“删除前缀起始位”批量修正手册专门提到这两个功能就是为了处理不规范的外部表。操作前提是选中行处于添加状态。修正完再做一轮抽样验证抽 20 个号码手工推演匹配结果跟系统实际计费结果比对。5.4 现象账户余额充足呼叫却被拒绝现象客户账户里明明有钱费率组也绑了拨号直接被拒话单里只有一条失败记录。原因三种可能按概率排序——费率类型与话机呼叫权限不匹配最常见号码段限制没放开该目的地被叫名单里有拦截条目。三者都是“与”关系任何一条不过就拒绝。解决排查顺序固定为费率类型 → 号码段 → 名单。费率类型这一项最容易漏因为它藏在费率条目里而不是账户里很多人只查账户。判断方法看这通呼叫命中的是哪条费率那条费率的费率类型是什么再看话机开通的权限级别是否覆盖该类型。5.5 现象话单时间与本地时间差几个小时现象查历史话单通话时间比实际拨打时间早了或晚了整小时数报表按小时聚合的结果全部错位。原因时区配置不一致。服务器系统时区、软交换参数里的时区、报表的展示时区三处任意一处不同就会出现整小时偏移。带夏令时的地区还会出现半小时偏移更难发现。解决统一到一处配置其余全部对齐。排查时先看系统信息确认服务器时间再看系统参数里的时区设置最后核对报表口径。改时区属于全平台影响的操作必须放在业务低峰改完立刻导出前一天话单核对时间戳。这条我吃过一次亏改完没验证第二天整个早高峰的报表全废。6. 用话单分析反推配置一套每月必跑的对账路径配置对不对最终只有话单能证明。我现在的习惯是每月初跑一遍固定路径四个动作半小时内完成。第一步数据报表 → 话费报表按费率组聚合看各组的收入占比与上月对比。占比突变超过 20% 的组逐个进去看是量变了还是价变了。价变通常是配置改动量变通常是线路调整两者的处理方式完全不同先分类再动手。第二步话单分析 → 接通分析按时段切找出接通率异常的小时。配合时段接通分析能定位到具体是哪个时段的哪条线路。这一步的价值是把“整体接通率 85%”这种没用的汇总数字拆成“凌晨 2 点到 4 点某线路只有 40%”这种能直接派工的信息。第三步话单分析 → 中断分析看短话单占比。短话单突然升高多半是媒体协商或对端拒接跟费率无关但会影响客户体验属于必须提前发现的那类问题。第四步抽样复算。从话单里随机抽 10 通通话把时长、命中的费率前缀、分段费率参数抄出来用脚本重算一遍金额跟系统结果比对。这个动作我写成了一段可以随手跑的小脚本def calc(duration, first_fee, first_sec, period_fee, period_sec, segmentsNone): 按 VOS3000 的分段费率 计费周期模型复算单通费用 duration : 通话时长秒 first_fee : 首次费率元 first_sec : 首次时长秒 period_fee : 计费费率元/周期 period_sec : 计费周期秒 segments : 可选[(序号, 金额, 计费时长), ...] 分段费率按序号升序 total 0.0 remain duration # 先走分段费率逐段扣减时长 for _, amount, seg_sec in (segments or []): if remain 0: break used min(remain, seg_sec) total amount # 分段金额按整段收取不按比例折算 remain - used # 超出分段总时长的部分按首次时长 计费周期计算 if remain 0: total first_fee over max(0, remain - first_sec) if over 0: cycles -(-over // period_sec) # 向上取整 total cycles * period_fee return round(total, 4) # 手册算例校验应在 0.51 print(calc(250, 0.21, 180, 0.15, 60))这段代码的关键在三处注释对应的地方。min(remain, seg_sec)是分段扣减的核心保证不会多扣amount整段收取而不是按时长比例折算这一点跟直觉相反配阶梯费率时必须确认业务口径-(-over // period_sec)是整数向上取整的惯用写法等价于math.ceil但不需要额外导入。参数里唯一需要按实际费率表改的是segments没有阶梯就传None。抽样复算连续三个月零差异之后我把频次从每月降到每季度但只要费率表动过当月必定补跑一次。从那以后我每次改费率都强制走一遍“导出 → 排序 → 手算三行 → 抽样复算”的流程哪怕只改了一个数字。这套动作看着笨但它把计费系统从黑匣子变成了能自证的东西。希望帮到你。本文还有配套的精品资源点击获取
