IOSOR 知识库

DID 携号转网:在大规模放量前进行实时冒烟测试

完成 DID 转网并不意味着可以盲目放量。在预付费账户余额上执行实时冒烟测试、验证 Webhook 并安全扩展流量。

1. 转网完成状态只是一个信号,而非放量绿灯

当控制面板(console)中的 DID 转网请求状态变更为«已完成»(Completed)时,这仅代表中央 LRN(位置路由码)数据库或国家级注册表更新了路由配置。这并不能保证每个下游本地交换运营商(LEC)或移动网络运营商(MNO)都已在其本地交换机中重新加载了最新的路由表,也无法确保您的入站短信 Webhook 已经完全激活并准备好处理高并发流量。在转网完成后立即将全量生产流量(尤其是关键的 OTP 验证码流量)切入新转入的 E.164 格式号码,往往会导致严重的投递失败、入站消息丢失以及终端用户的负面反馈。在电信运营的最佳实践中,转网完成仅仅是启动系统性冒烟测试的邀请,而非直接放开流量洪闸的许可。

2. 第一步:入站与出站冒烟测试与 DLR 监控

在引导实际的生产应用流量之前,必须在受控的沙盒或低频环境中运行单目标双向测试。首先,从主流的外部移动网络向新转入的号码发送手动测试短信,登录控制面板(console)实时检查入站 Webhook 是否能准确接收到包含完整有效负载(payload)的 JSON 数据。其次,执行出站测试,验证系统是否能成功向外部终端投递消息,并密切监控递送报告(DLR)的状态返回。通过分析 DLR 状态码,可以确认是否存在路由挂起、短信中心(SMSC)绑定丢失或运营商同步延迟等底层问题。在低流量下进行双向测试,能够在真实用户遇到验证码延迟或消息丢失之前,主动暴露并解决这些隐性故障。

3. 第二步:Webhook 投递、E.164 格式化与 OTP 验证

入站路由的稳定性高度依赖于精确的 JSON Webhook 投递机制和严格的 E.164 国际标准格式化。在控制面板中,确保您的 Webhook 接收端点配置正确,并能在标准 SLA 响应时间内无延迟地接收到推送数据。验证转网号码在传输过程中是否保持了完整的国际格式(例如 +86 或 +1 等前缀),且没有丢失国家区号或前导零。在即时(JIT)分配或动态转网 DID 激活期间,平台会动态预留并分配最优的流量路径。如果入站 Webhook 在低速率冒烟测试期间返回 HTTP 5xx 错误、超时或签名校验失败,必须立即修复您的应用端点,切勿在此阶段引导任何真实的 OTP 验证码或双因子认证(2FA)流量。

4. 第三步:阶梯式流量放量与预付费钱包底线管理

新转网号码的流量扩展必须遵循严密的阶梯式放量策略:在数小时或数天内,按照 5%、25%、50% 直至 100% 的比例依次递增。这种渐进式的方法不仅能保护您的发信通道和发送 IP 的投递声誉,还能让运营团队有充足的时间进行实时余额监控。请务必记住,实时通信平台的路由引擎是运行在严格的预付费钱包(prepaid wallet)账本之上的。为了防止在高并发流量激增期间因余额不足而导致服务瞬间中断,您必须在预付费钱包中保持至少 20 美元(USD 20 floor)的强制性最低余额底线。当您的月度消费接近 1,000 美元/月的软性审核线时,系统将自动评估您的账户参数与信用额度,以确保持续、无阻碍的投递吞吐量。

5. 验证协议与运营手册

为了构建一个具有高弹性和容灾能力的消息传递架构,请将您的转网验证流程与标准入职清单以及动态号码分配策略深度结合。定期审查针对发布周、预付费钱包余额分配、DLR 异常排查以及即时故障响应的标准化运营流程。

6. 从 IOSOR 开始构建

转网状态变成 complete 时先做冒烟,不要开闸。在已转的 E.164 上各发一条入站和出站。确认 webhook 载荷和终态 DLR。然后才按 5、25、50、100 爬升。导出这段冒烟窗口,放量不能靠猜。

IOSOR 要点

转网完成是冒烟邀请,不是放量绿灯。

要做:双向冒烟,再阶梯爬升。不要:控制台一写 complete 就群发。

这篇指南有帮助吗?

相关指南