題幹與適用場景
多個電話服務提供商無法保證 SIP 訊令攜帶 PASSporT。請依 RFC 9888 設計帶外 Call Placement Service（CPS），說明服務發現、提交與檢索、mTLS 授權、過期控制、閘道互通與隱私風險。
RFC 9888 針對大型服務提供商在 SIP 無法可靠端到端傳遞時，透過 HTTP 讓 OOB Authentication Service（OOB-AS）向 CPS 提交 PASSporT，再由 OOB Verification Service（OOB-VS）拉取或接收推送。題目重點是信任邊界與生命週期，不是實作普通 REST 儲存桶。
面試官考察點
面試官會看你能否區分 STIR 憑證、PASSporT、CPS、OOB-AS 與 OOB-VS 的職責；能否設計可信的 CPS 廣告與電話號碼範圍授權；能否用 mTLS、租戶額度與短過期時間防止偽造、重放與洪泛；以及能否解釋多供應商檢索、閘道轉換、隱私收集與故障降級。
回答前需要釐清的問題
參與者與網路邊界
先確認誰簽發 PASSporT、誰營運目標服務提供商的 CPS、OOB-VS 是拉取還是訂閱推送，以及哪些鏈路經過 PSTN 閘道或傳統網路。
真實性與隱私目標
確認系統要證明主叫身分、降低號碼冒用，還是還要隱藏通話雙方中繼資料。RFC 9888 的服務提供商 CPS 本來就屬於通話參與方，隱私模型與開放網際網路 OOB 服務不同。
延遲與保存期限
確認來電提示最多能等待多久、允許多少時鐘偏差，以及 PASSporT 是否只需保存到驗證完成。不能把 CPS 當成長期歸檔庫。
30 秒回答框架
「我會按目標服務商的 SPC 或號碼範圍發布簽名的 CPS 廣告，OOB-AS 用受信任的 STIR 憑證和 mTLS 向 CPS 提交 PASSporT，CPS 按目標號碼授權、限流並只保存到 PASSporT 新鮮度視窗內。OOB-VS 可以在收到通話後拉取，也可以按號碼範圍訂閱推送；多供應商場景必須校驗 dest 與 TNAuthList 的授權關係。閘道只做協定轉換，不擴大權限。全鏈路記錄過期、重複、未授權與延遲指標，並把 CPS 的中繼資料收集寫入治理邊界。」
分步驟深入解答
第一步：劃分信任與資料流
OOB-AS 產生或攜帶 PASSporT，向目標 CPS 提交；CPS 根據廣告與本地策略接收；OOB-VS 只取得自己有權驗證的目標號碼範圍。驗證服務仍需檢查 PASSporT 的簽章、orig、dest 與新鮮度，不能因為來源是 CPS 就跳過驗證。
第二步：安全發布 CPS 廣告
廣告把 SPC 或電話號碼範圍映射到 HTTPS CPS URI。廣告應由受信任的 STIR 憑證簽章，接收方比對簽章者的 TNAuthList 與被宣傳範圍，防止任意持證方劫持一個號碼範圍。發現可透過設定、資料庫或安全 DNS 流程完成，但快取必須帶版本與失效策略。
第三步：提交介面與授權
OOB-AS 與 CPS 建立 TLS，優先使用 mTLS，並檢查憑證是否屬於允許提交的服務提供商。CPS 按服務商、號碼範圍與速率做配額，拒絕未知憑證、錯誤目標或過量請求。提交介面應回傳可觀測的接受、拒絕與重複狀態，但不回傳可幫助攻擊者試錯的內部策略。
第四步：保存與過期
PASSporT 只保存到檢索所需時間，且不超過其新鮮度視窗；RFC 9888 描述的上限是 60 秒。以 orig、dest、通話識別與 PASSporT 唯一資訊建立去重鍵，避免同一物件被無限重放。過期清理應是強制約束，而不是依賴低頻背景工作。
第五步：拉取與推送檢索
拉取模型在收到沒有內嵌 PASSporT 的通話後查詢 CPS；推送模型按號碼範圍或 SPC 訂閱，將物件主動送給獲授權的 OOB-VS。多供應商 CPS 必須檢查 PASSporT 的 dest，確保只把物件交給對應服務商。推送失敗不能改變簽章有效期，驗證方應明確區分「暫時沒有憑證」與「憑證無效」。
第六步：閘道與降級
閘道可以從 SIP INVITE 擷取 PASSporT 並提交給面向傳統 PSTN 的 CPS，也可以把 OOB 物件轉換為下游可理解的形式。閘道憑證應被授予明確的代理範圍，不能把一個服務商的權限擴展到整個網路。CPS 不可用時繼續接通並標記未驗證，還是阻斷高風險通話，應由產品與監管策略決定。
第七步：隱私、監控與演練
CPS 會接觸電話中繼資料，需限制欄位、保留時間與存取稽核。指標至少包括提交成功率、未授權率、重複率、過期率、拉取延遲、推送積壓與按服務商的配額拒絕。測試應涵蓋憑證撤銷、號碼範圍重疊、重放、跨供應商讀取、廣告被改寫、PSTN 閘道斷鏈與 CPS 局部故障。
高品質示範回答
我會先登記參與方與授權範圍：每個目標服務商發布由其 STIR 憑證簽名的 CPS 廣告，廣告把 SPC 或號碼範圍綁定到 HTTPS URI。OOB-AS 用 mTLS 向目標 CPS 提交 PASSporT，CPS 校驗憑證、dest、範圍與額度，並只保存到新鮮度視窗結束；RFC 9888 描述的最長保存時間是 60 秒。OOB-VS 可以在沒有內嵌 PASSporT 的來電到達後拉取，也可以按號碼範圍訂閱推送。多供應商 CPS 必須根據 dest 與 TNAuthList 做讀取授權。PSTN 閘道只能使用委派範圍執行擷取或轉換。系統應區分憑證缺失、憑證過期與簽章無效，按策略降級，同時稽核中繼資料存取並監控洪泛、重放、延遲與配額拒絕。
常見錯誤
- 錯誤表現： 把 CPS 當成公開物件儲存。→ 失敗原因： 未授權的提交與讀取會造成偽造、資料外洩與洪泛。→ 修正方法： 用受信任憑證、mTLS、號碼範圍授權與服務商配額限制存取。
- 錯誤表現： 把 PASSporT 長期保存以便追查。→ 失敗原因： 超過新鮮度視窗會擴大重放與中繼資料暴露。→ 修正方法： 以驗證完成為目標設定短 TTL，並強制過期刪除。
- 錯誤表現： 只按 orig 決定誰能讀取。→ 失敗原因： 多供應商必須同時約束 dest 與服務商擁有的 TNAuthList。→ 修正方法： 在提交與檢索兩側都做目標範圍授權。
- 錯誤表現： 閘道擷取物件後直接信任。→ 失敗原因： 閘道改變了傳輸位置，沒有取代簽章驗證。→ 修正方法： 保留 PASSporT 驗證流程，並給閘道最小委派權限。
追問及應對
如果 OOB-AS 的 mTLS 憑證洩露怎麼辦？
立即撤銷憑證、停止其提交權限並按服務商範圍隔離；對已提交物件仍按 PASSporT 新鮮度與簽章驗證處理，不能只依賴連線身分。
為什麼需要簽名 CPS 廣告？
廣告決定 PASSporT 應提交到哪個 CPS。簽名把 CPS URI 與 SPC 或號碼範圍綁定，避免攻擊者把合法服務商的流量導向自己的收集點。
拉取與推送如何選擇？
拉取實作簡單並按實際來電觸發；推送可降低驗證等待，但需要訂閱授權、積壓處理與撤銷訂閱。大規模部署可按服務商與號碼範圍混合使用。
CPS 暫時不可用，通話要不要阻斷？
先區分防騷擾提示與強監管阻斷。普通來電可以繼續接通並標記未驗證；高風險場景可延遲或阻斷，但必須把策略、逾時與誤傷指標納入產品決策。