DID 綁定前的 E.164 正規化：加號、零與空格

為什麼未處理的號碼輸入會破壞路由

接受未經清理的原始使用者電話號碼輸入，是導致路由靜默丟失的主要原因。當租戶貼上包含開頭雙零、缺少加號、連字號或隨機空白的號碼時，系統便無法配對目的地設定檔。在我們的預付費 CPaaS 模式中，隨需 (JIT) 佈建意味著號碼是動態請求並即時綁定的。如果傳入格式背離了嚴格的 E.164 標準，webhook 處理常式就會無法註冊綁定。這種不匹配會阻止帳本將傳入的通話或簡訊與正確的子帳戶關聯。結果就是封包被拒絕，且您的客戶失去了一次轉換機會。這裡有個陷阱：許多舊系統仍在使用包含國內碼前綴的本地撥號計畫，在進行綁定之前必須將其去除。

國際格式的正規化規則

嚴格的正規化要求在進行任何資料庫查詢或綁定嘗試之前，將所有傳入的數字字串轉換為規範的 E.164 標準。此程序會去除所有格式化字元，包括空格、括號、句點和破折號。它會將諸如 '011' 或 '00' 等本地國際撥號前綴替換為標準的 '+' 號，並根據租戶的預設語系，在省略時加上正確的國碼。例如，像 «+1 (555) 019-2834» 這樣的輸入必須儲存為 «+15550192834»，以確保路由表正常運作。如果沒有這種一致性，即使號碼在您的庫存中是處於活動狀態，您的 API 也會傳回 404 錯誤。當系統根據預付費餘額計算每分鐘費率時，每個數字都至關重要。

處理租戶入口網站中的邊緣案例

租戶入口網站經常引入隱藏的異常狀況，例如零寬空格、結尾換行符號或來自舊版 PBX 系統的開頭國際退出碼。您的前端驗證必須在酬載到達 API 閘道之前攔截這些異常狀況。當執行批次作業時，髒字串經常會繞過單欄位檢查。營運商應套用嚴格的 CSV 衛生協定以確保資料完整性。如果租戶上傳了包含 1,000 個號碼的清單，單個格式錯誤的字串就可能導致整個佈建佇列停滯。我們建議使用基於正規表示式的篩選器，強制執行 '+' 前綴和最多 15 位數字。這可以防止在批次綁定執行到一半失敗時，需要花費數小時進行手動疑難排解。

防止綁定不匹配與靜默丟失

當號碼綁定請求因為格式差異而失敗時，平台可能會傳回通用錯誤，或者更糟的是，處理導致流量路由錯誤的部分匹配。追蹤行銷活動指標的租戶將會注意到遺漏的 DLR 以及沒有回應的 webhook。維持嚴格的正規化可防止這些靜默不匹配。如果訂單確實因為上游電信商同步逾時而遇到佈建錯誤，請檢閱 /learn/did-order 中概述的標準程序。乾淨的 E.164 字串可確保綁定是唯一的，並且每月經常性費用 (MRC) 的扣款會套用到正確的帳本條目。不要讓系統猜測格式；如果輸入不明確，請立即拒絕請求以保護路由邏輯。

指派後監控與試行階段

一旦 E.164 正規化成功且號碼順利綁定，營運生命週期就會轉移到主動監控階段。在初始推出期間，租戶應密切追蹤傳遞率與 HB 信號。若要了解如何在部署的第一週評估效能，請參考 /learn/did-pilot-after-assign 中的指引。及早監控流量模式有助於偵測出由區域電信商特性引發的任何殘餘路由異常。如果您看到大量的 '480 Temporarily Unavailable' 回應，請檢查正規化邏輯是否意外去除了該特定區域所需的數字。使用一小部分號碼進行試行階段，是驗證您的正規化邏輯在實際流量負載下是否穩健的最佳方法。

從 IOSOR 開始

只有改寫成 E.164 之後才綁定一個 DID：前置加號、國碼、無空白、無中繼零。原始輸入與正規形式並排寫進指派匯出。綁定欄還留著 00 或帶空白的數字，就拒絕綁定——不要承諾「上量後再洗」。這是所有權之前的格式閘，不是把 STOP 寫入名單，也不是依 webhook 找租戶。

相關: 來電顯示與簡訊傳送者身份辨識：語音上線不等於 SMS 已可正常運作 上行 MO 傳送至抑制清單：DID 上的 STOP 指令保護發送信譽 首次扣款前的預付資金保留.

IOSOR 要點

把本地格式存進綁定，就是路由說謊。指派表只收 E.164，否則不許綁定。

要做：先正規，再綁定，再匯出兩種形式。不要：先綁後改，或把加號、零、空白當成化妝。