日本电信基础设施正在经历自私有化以来最重大的技术代际更迭。NTT 东日本与 NTT 西门子共同部署的固定电话网（PSTN）于 2024 年 1 月启动全面 IP 化迁移，这一工程直接影响了日本企业级呼叫中心广泛依赖的 NaviDial（ナビダイヤル，0570 开头）和 FreeDial（フリーダイヤル）服务。对于仍运行在传统电路交换网络上的业务系统而言，理解这场迁移的技术细节、识别受影响的功能模块、制定切实可行的切换方案，已成为维持服务连续性的必修课题。
PSTN 架构与 NaviDial 服务原理
NaviDial 是 NTT 提供的全国统一接入号码服务（类似中国的 400 电话），企业将 0570 开头的服务号码作为统一客服入口，由 NTT 网络根据预设的路由规则将来电转接至实际业务坐席。这一服务构建在传统的 PSTN 基础设施之上，依托以下几层技术实现：
电路交换层：NTT 的东西两家公司各自维护独立的电路交换网络，使用 ISDN（INS ネット）或模拟中继（加入電話）作为最后一公里接入。呼叫在进入 NaviDial 平台前，先经过地方交换机的 7 号信令（SS7）进行号码解析和路由选择。
智能路由层：NaviDial 平台提供基于主叫位置的路由（発信地域ルーティング）、基于时间段的转接（時間指定接続）、ACD 自动分配（ACD グループ）、排队等待（話中時待合わせ）等增值功能。这些功能依赖 PSTN 网络传递的 ANM（Answer Message）和 ACM（Address Complete Message）信号来触发。
计费分离层：传统的 NaviDial 支持全国统一计费（全国一律課金）和分担计费（分担課金），即企业可灵活设定发话方与受话方之间的费用分摊比例。这一功能依赖于 PSTN 网络对通话区位的识别能力。
正是这三层架构的深度耦合，使得 IP 化迁移必然带来功能重构。根据 NTT 官方发布的《PSTN マイグレーションに伴う終了・変更と》文档，PSTN 网络设备已接近维护寿命临界点，2024 年起强制切换至 IP 网（IP 網への移行）。
受影响功能清单与时间节点
NaviDial 和 FreeDial 的 IP 化迁移并非一次性完成，而是分阶段推进。部分功能在新架构下无法兼容或需要重新开发，被直接终止；部分功能参数因 IP 网络的特性而调整。工程师在制定迁移计划时，首先需要对照下表清点当前使用的功能：
已终止服务（2023 年 6 月 30 日截止）：迷惑电话拒绝功能类型 1（迷惑電話お断りタイプ 1）依赖 NTT PSTN 网络的拨号操作进行黑名单登记，IP 化后该操作接口已不存在。细分化代码功能（細分化コード指定）允许在东京 23 区、大阪 06 区名古屋 052 区内部进一步按区级划分接听策略，但 IP 网络的信令无法携带如此精细的位置信息，故一并废止。通话量设定（通話量設定）用于限制总呼叫次数，IP 化后改由用户侧 PBX 或云平台实现。代理功能（エージェント機能）支持根据坐席忙碌状态动态分配来电，该功能在 IP 化后需迁移至 SIP 层面的代理服务器实现。
延期终止服务（2024 年 1 月 1 日）：全国统一计费（全国一律課金 10 円 / 1 分）、分担计费（ナビダイヤル分担課金）、迂回时差额负担（迂回時差額負担）三项计费相关功能原计划于 2023 年废止，因 IP 化工程整体延期而推迟至 2024 年初。迁移完成后，通话费用将不再区分发话地域，全国统一按固定费率计算。
参数调整服务（2023 年 7 月 1 日起分批切换）：话中等待（話中時待合わせ）的最大等待时间从 5 分钟压缩至 2 分钟，理由是 IP 网络中语音缓冲队列的内存成本高于传统电路交换。无应答迂回 / 引导（無応答時迂回 / ガイダンス）的触发阈值从 3 至 175 秒压缩至 3 至 120 秒。ACD 组成员上限从 500 号码削减至 100 号码。话中迂回检测时间从 5 秒延长至 10 秒，迂回次数上限从 4 次提升至 9 次 —— 这两项调整反映了 IP 网络在信令延迟上的差异，延长检测窗口可避免误判。
迁移工程关键参数设计
当企业决定从传统 PSTN 中继迁移至 SIP 中继或云语音平台时，以下工程参数需要重新设计和验证。
SIP 中继对接参数：若选择自建 PBX 对接 SIP 中继，需确保 PBX 支持 RFC 3261 标准 SIP 协议，并配置 NAT 穿透策略。NTT 的 IP 互联（IP 相互接続）采用 UDP 传输 5060 端口，建议将 SIP 超时参数设置为、T1=500ms（ Provisional 响应超时）、T2=4s（最终响应超时）。对于需要保持原有 NaviDial 号码的场景，需向运营商申请号码携带（番号ポータビリティ），通常需要 10 至 15 个工作日的测试窗口。
排队与等待参数调整：原 PSTN 环境下的话中等待支持最长 5 分钟，但 IP 化后上限为 2 分钟。如果业务场景需要更长的等待队列，建议在 PBX 侧实现本地排队（例如 Asterisk 的 Queue 模块配合 waittime 参数），而非依赖运营商的等待功能。同时需将等待音乐的编码从 G.711 μ-law 改为 OPUS，以降低带宽消耗并在低带宽环境下保持音质。
路由策略重新配置：细分化代码功能在 IP 化后无法精确至区县级别。如果业务原本依赖 “仅接受东京 23 区及狛江市来电” 的精细策略，迁移后需退化为 “仅接受东京全区”，或者在上层 PBX 通过 SIP 头的 X-Originating-IP 字段结合 GeoIP 数据库自行实现二次筛选。后者需要在 SIP INVITE 请求到达 PBX 后增加 20 至 50ms 的处理延迟，需评估对整体接通率的影响。
计费与分摊逻辑：IP 化后全国通话统一费率，原本基于区位的计费分摊逻辑不再适用。如果业务仍需按部门或业务线统计通话成本，建议在 PBX 侧记录 CDR（通话详细记录），按 SIP 头的 X-UCID（唯一通话标识）进行二次计费。CDR 的记录字段建议包含：呼叫开始时间、持续时长、主叫号码、被叫号码（SIP URI）、QoS 参数（RTP 丢包率、抖动值）。
替代方案选型评估
对于 NaviDial 功能重度依赖的企业，主要有三条迁移路径：
运营商托管方案：NTT 自身的 Arcstar IP Voice 服务提供与原 NaviDial 功能近似的呼叫中心解决方案，支持 SIP 中继接入、智能路由、ACD 排队。该方案的优势是配置迁移工作量最小，缺点是功能参数调整空间有限，且部分原 NaviDial 特有的选项（如细分化代码）无法完全复现。根据 NTT 官方定价，SIP 中继的通话费用为固定电话 8 日元 / 3 分钟、移动通信 16 日元 / 1 分钟。
云通信平台方案：主流选择包括 Twilio、Vonage、Bandwidth 等美国云通信平台，或日本的 Altan、IIJ 等本地服务商。云平台的优势在于弹性扩展能力和丰富的 API 集成能力，可通过编程实现细分化路由和高级 ACD 策略。但需注意日本本地的通信 regulations 要求，云平台号码的来显规范可能与 0570 号码不同，且部分银行和金融机构对非本土运营商的号码存在信任度差异。
混合架构方案：保留一部分传统 PSTN 中继作为备份，新业务全量走 SIP 中继。混合架构的关键工程点在于：主备切换的触发条件（建议设定为 SIP 中继连续 3 次呼叫失败或 RTP 丢包率超过 5%）、双平面计费的对账逻辑、以及 IVR 流程的同步播放。
实施检查清单与监控要点
在执行迁移切换时，建议按以下清单逐项验证：
第一，确认所有在用的 NaviDial 选项是否在终止清单中，如已使用迷惑电话拒绝类型 1 或细分化代码，需在切换前完成业务逻辑的替代实现。第二，测试 SIP 中继的呼叫建立时延，原 PSTN 的端到端延迟通常在 100ms 以内，而 SIP 中继经过 NAT 穿透和媒体协商后可能达到 300 至 500ms，如超过业务容忍阈值需优化 SDP 协商参数。第三，验证 CDR 计费对账脚本在新环境下可正确解析 SIP 头的 X-UCID 字段与时间戳。第四，确认原绑定在 NaviDial 上的短信通知功能（如果使用）在 IP 化后是否仍可工作，部分短信网关依赖 PSTN 的 SMS 传递协议。第五，安排为期两周的并行运行期，在此期间同时接听 PSTN 和 SIP 两个平面的来电，比对接通率、投诉率和音质主观评分。
监控指标方面，建议跟踪以下核心 SLA：SIP 中继可用性目标 99.95%（对应月度累计中断不超过 22 分钟）、呼叫建立成功率目标 98.5%、平均通话建立时延目标小于 800ms、RTP 音频质量 MOS 分数目标 3.5 以上。这些指标应通过 Prometheus+Grafana 或商业呼叫中心监控平台进行实时可视化。
结语
日本 PSTN 的 IP 化迁移不是一次简单的网络升级，而是对整个企业语音通信架构的重新设计。NaviDial 服务在传统 PSTN 网络上运行二十余年，积累了大量基于电路交换特性的功能假设，这些假设在 IP 环境中不再成立。企业在评估迁移方案时，应首先完成当前功能使用的完整审计，再根据业务对路由精细度、等待时长、计费分摊等参数的敏感度，选择合适的替代路径。对于呼叫中心规模超过 50 坐席的企业，建议预留 3 至 6 个月的并行测试周期，并在切换后持续监控关键质量指标至少一个完整业务季度。
资料来源：本文技术细节主要依据 NTT 官方发布的《PSTN マイグレーションに伴う終了・変更と》文档，涵盖各选项服务的终止时间表与参数变更阈值。