IOSOR 知識庫
E.164 清潔不是 HLR 查詢
了解為什麼本地 E.164 格式化與 NANP 覆蓋驗證不同於即時 HLR 查詢,以及如何架構您的 IOSOR 路由帳本。
E.164 清潔是一個嚴格的語法驗證過程,與即時的歸屬位置暫存器 (HLR) 查詢本質上是不同的操作。前者是離線的、確定性的、基於規則的檢查,而後者是線上即時的、可能產生費用的網路互動,用於確定行動電話號碼的活躍狀態和歸屬網路。將這兩者混淆會導致不必要的成本和處理延遲。
格式與狀態的核心差異
E.164 清潔是一個確定性的離線過程。它解析字串以確保其符合 ITU-T E.164 標準,該標準將電話號碼限制為以加號開頭的 15 位數以內。此步驟透過數學方式驗證國家代碼與國家目的地代碼,例如檢查國家代碼是否有效且與後續數字組合符合預期。它不會查詢電信網路來查看該訂戶是否存在、是否正在漫遊或已被斷線。這純粹是一項結構檢查,旨在確保地址在語法上是正確的,為後續處理做好準備。在進入任何高成本的即時查詢階段之前,執行此步驟可以過濾掉超過百分之九十的格式錯誤輸入,例如包含無效字元、過長或過短的號碼,從而避免不必要的 API 開銷並提升系統處理效率,確保只有格式正確的號碼進入下一驗證層級。
本地解析與 NANP 覆蓋規則
在北美洲號碼計畫 (NANP) 中,區號覆蓋需要嚴格的十位數撥號,這意味著某些地區的號碼在撥打時需要包含區號。本地解析庫透過檢查區域資料庫來即時處理這些規則,確保號碼在撥打時符合當地的撥號習慣和路由要求。這項資料品質步驟可確保地址在任何封包離開您的伺服器之前是可路由的,避免因撥號規則不符而導致的路由失敗。它防止了基本的格式錯誤在電信業者閘道失敗,從而節省處理週期而不會引入網路延遲。這種本地驗證對於維護高品質的聯絡人清單至關重要,且無需支付外部網路查詢費用。此外,本地解析還可以結合特定國家或地區的安靜時間 (quiet hours) 規則,例如在深夜或法定的靜音時段自動暫緩非必要的驗證或發送,以確保您的外撥通訊符合當地的合規與電信法規,並尊重用戶的休息時間。這也包括了對特定時間段內 OTP 發送的限制,以避免打擾用戶。
即時 HLR 查詢作為獨立的帳本事件
HLR 查詢是對行動網路營運商的歸屬位置暫存器進行的即時查詢。它會檢索活躍的網路狀態、行動國家代碼 (MCC)、行動網路代碼 (MNC) 以及攜碼歷史記錄,以確定號碼當前是否活躍以及其歸屬網路。由於這會查詢即時信號資料庫,因此會在您的帳本中產生每筆查詢的費用,這通常是按次計費的。為了防止濫用並確保平台穩定性,IOSOR 強制執行 20 美元 (USD 20) 的預付費錢包最低底線 (floor) 來啟動即時查詢,並對高吞吐量帳戶在接近每月 1,000 美元時進行軟審核,以監控潛在的異常活動。這項 20 美元的帳戶餘額限制可確保您的預付費錢包有足夠的資金來支付即時信號查詢的成本,避免因餘額不足而導致關鍵路由中斷,確保服務的連續性。
優化路由成本與避免延遲
透過將 E.164 清潔與 HLR 查詢分開,您可以保護您的應用程式免受不必要的延遲和高昂交易費用的影響。在您的註冊表單執行離線 E.164 格式驗證,以確保字串乾淨且符合標準。只有在需要驗證號碼是否能接收 OTP 或 SMS 時,才觸發 HLR 查詢。這種混合方法可保持您的資料庫原始,同時最大限度地降低交易成本,確保您僅在確保投遞絕對必要時才為即時查詢付費。此外,這能大幅降低系統的整體延遲,因為本地解析只需要幾微秒,而即時網路查詢則需要數百毫秒的往返時間,這對於需要快速響應的應用程式至關重要。
將驗證整合到您的應用程式流程中
為了建立穩健的流程,請在入口處驗證 E.164 格式,然後使用 webhook 接收 DLR 狀態。在實際發送中,DLR (遞送收據) 與 webhook 的回傳數據才是判斷號碼是否真正可達的最終真實來源 (DLR/webhook truth)。如果號碼未通過本地驗證(例如格式錯誤或不符合 NANP 規則),請立即拒絕它。如果通過,您可以選擇執行 HLR 查詢以確認活躍狀態,這對於需要高準確度的 OTP 發送尤為重要。這可防止向無效目的地發送訊息,並有助於管理 STOP 請求,確保用戶的意願得到尊重。您必須建立即時的退訂同步 (opt-out sync) 機制,一旦收到使用者的拒收信號,立即在本地資料庫與路由帳本中同步更新,避免向已退訂的號碼發送後續內容,這對於遵守法規和維護用戶信任至關重要。有關實施這些步驟的更多詳細資訊,請探索我們的技術指南:
從 IOSOR 開始
若要落實此隔離,請開啟 IOSOR 主控台並設定入站規則,在流量抵達路由引擎前攔截非 E.164 字串。您可建立本機解析閘道,即時處理 NANP 重疊規則,無須發動外部網路請求。透過僅針對路由設定檔中的合格位址啟用即時查詢,為高價值驗證步驟節省 HLR 查詢額度,並確保您的預付費錢包始終有足夠的餘額來應對必要的即時查詢。
IOSOR 要點
本文證明資料清潔與網路狀態查詢是兩項截然不同的操作,必須在管線的不同階段處理。E.164 格式化是零成本的數學驗證步驟,確保號碼在發送流量前符合國際標準與區域重疊規則。HLR 查詢則是確定號碼活躍狀態的即時網路操作,會產生費用。
請在資料輸入點執行本機解析程式庫,立即過濾格式錯誤的字串。切勿以即時 HLR 查詢取代基本語法與前綴驗證,以免浪費預算並引入延遲。利用 DLR 和 webhook 驗證最終遞送狀態,並確保預付費錢包有足夠餘額以應對必要的即時查詢,例如 OTP 發送前的驗證。
這篇指南有幫助嗎?
相關指南
- 無效的 MSISDN 絕對不能進行扣款
了解 IOSOR 平台如何在入口處攔截無效的 E.164 電話號碼,防止錯誤的帳本扣款並保護您的預付餘額。
- 發送前的 NANP 重疊區號:財務數據質量指南
了解如何解析北美電話區號計劃 (NANP) 重疊區號以防止計費錯誤。確保您的財務團隊在發送流量之前引用正確的費率分區。