本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用電話集區的 RCS 到 SMS 備用
電話集區是傳訊身分的容器，例如 AWS RCS 代理程式和簡訊電話號碼，可在您的 API 請求和基礎起始身分之間提供抽象層。集區可簡化組態變更、數字類型遷移和 RCS-to-SMS 備用。您傳送單一 API 呼叫至集區， AWS 而最終使用者傳訊會為您處理頻道選擇。
本章說明 RCS 交付可能失敗的方式、簡訊退避可能的原因、退避邏輯和優先順序，以及帳單影響。它還涵蓋pool-per-use-case最佳實務，以及如何從集區新增和移除 AWS RCS 代理程式。如需電話集區的一般資訊，請參閱 [AWS 最終使用者簡訊簡訊中的電話集區](phone-pool.md)。如需管理 AWS RCS 代理程式的資訊，請參閱 [管理 RCS 代理程式](rcs-agents.md)。
**Topics**
+ [RCS 交付如何失敗](#rcs-sms-fallback-how-rcs-fails)
+ [讓 SMS 退避成為可能的原因](#rcs-sms-fallback-what-makes-possible)
+ [為什麼要使用集區](#rcs-sms-fallback-why-pools)
+ [Pool-per-use-case 模型](#rcs-sms-fallback-pool-per-use-case)
+ [帳戶層級傳送的合規風險](#rcs-sms-fallback-compliance-risk)
+ [備用邏輯和優先順序](#rcs-sms-fallback-logic)
+ [SMS 後援的帳單影響](#rcs-sms-fallback-billing)
+ [測試 SMS 備用](#rcs-sms-fallback-testing)
+ [在集區中管理 AWS RCS 代理程式](#rcs-sms-fallback-pool-management)
## RCS 交付如何失敗
RCS 交付可能會失敗，原因有幾個。了解這些失敗模式可協助您規劃備用策略：
+ **電信業者不支援 RCS** — 收件人的行動電信業者尚未在其網路上啟用 RCS 訊息。
+ **裝置不支援 RCS** — 收件人的裝置沒有 RCS 功能 （例如，較舊的 Android 裝置或執行 iOS 的 iPhone 早於 18)。
+ **客服人員在電信業者上未處於作用中**狀態 — 您的 AWS RCS 客服人員尚未獲得收件人的電信業者核准，或客服人員在該國家/地區處於「部分」狀態。
+ **裝置暫時無法連線** — 收件人的裝置支援 RCS，但暫時離線或沒有資料連線。RCS 訊息需要資料連線才能交付。
當任何這些條件發生且您使用以集區為基礎或帳戶層級的傳送時， AWS 最終使用者傳訊會自動回復為使用相同集區或帳戶的電話號碼傳送簡訊。
## 讓 SMS 退避成為可能的原因
SMS 備用需要 AWS RCS 代理程式和相同集區中至少一個 SMS 電話號碼。當您傳送訊息至集區時， AWS 最終使用者傳訊會先嘗試 RCS 交付。如果 RCS 交付失敗，服務會使用相同集區的電話號碼，透過簡訊重試訊息。只有 AWS RCS 代理程式 （且沒有電話號碼） 的集區不支援 SMS 備用。如果 RCS 失敗，則不會傳遞訊息。
**重要**
若要讓簡訊後援正常運作，您的集區必須同時包含 AWS RCS 代理程式和一或多個簡訊電話號碼。只有單一身分類型的集區不提供跨頻道備用。
## 為什麼要使用集區
我們建議對所有簡訊使用案例使用電話集區，而不只是 RCS。集區提供下列優點：
+ **自動簡訊備用** — 當集區同時包含 AWS RCS 代理程式和簡訊電話號碼時， AWS 最終使用者傳訊會先嘗試 RCS 交付。如果 RCS 交付失敗 （例如，收件人的裝置或電信業者不支援 RCS)，服務會自動使用相同集區的電話號碼透過 SMS 重試訊息。您不需要在應用程式中實作備用邏輯。
+ **智慧型路由** — 服務會根據目的地、頻道可用性和黏性傳送歷史記錄，從集區中選取最佳的起始身分。此路由會在每次`SendTextMessage`呼叫時透明地發生。
+ **單一 API 呼叫** — 您可以在`SendTextMessage`請求中將集區 ID 指定為起始身分。該服務會決定要透過 RCS 還是 SMS 傳遞，而不需要任何額外的邏輯。
+ **未來變更的彈性** – 您可以隨時從集區新增或移除電話號碼和 AWS RCS 代理程式，而無需變更應用程式碼。例如，您可以新增 SMS 退信的免付費電話號碼，或交換 10DLC 號碼，而無需修改您的傳送整合。
+ **不收取費用或下行** — 建立集區並將起始身分新增至集區，不會產生額外費用。即使使用單一電話號碼或單一 AWS RCS 代理程式，使用集區仍可讓您彈性地稍後新增更多身分，而無需變更應用程式。
**注意**
我們建議一律使用 集區傳送簡訊。即使具有單一起始身分，使用集區也不會產生任何成本或缺點。對於 RCS-to-SMS備用，集區必須包含 AWS RCS 代理程式和至少一個簡訊電話號碼。從集區開始，表示您可以稍後新增簡訊備用號碼或其他 AWS RCS 代理程式，而無需修改您的傳送程式碼。
## Pool-per-use-case 模型
我們建議為每個使用案例建立一個集區。每個集區都應包含所有電話號碼，以及提供單一訊息用途的 AWS RCS 代理程式。例如：
+ OTP 代碼**的交易集**區和帳戶通知，其中包含您的 AWS RCS 代理程式和註冊交易簡訊的 10DLC 號碼。
+ 促銷訊息的**行銷集區**，其中包含相同的 AWS RCS 代理程式 （或其他代理程式） 和註冊行銷的免付費電話號碼。
+ **預約提醒集區**，用於排程通知，其中包含您的 AWS RCS 代理程式和預約相關訊息的專用電話號碼。
此模型可確保當 RCS 交付失敗且服務落回 SMS 時，後援訊息會從針對相同使用案例註冊和核准的電話號碼傳送。這可確保您的簡訊符合電信業者要求和註冊條款。
## 帳戶層級傳送的合規風險
當您在帳戶層級傳送訊息 （不指定集區或起始身分） 時， AWS 最終使用者傳訊會從您帳戶中的所有可用身分中選取起始身分。如果您的帳戶有多個註冊不同使用案例的電話號碼，服務可能會選取與您訊息內容不相符的電話號碼。
**重要**
使用混合使用案例進行帳戶層級傳送會產生合規風險。例如，如果您的帳戶有註冊 OTP 訊息的 10DLC 號碼和註冊預約提醒的免付費電話號碼，則可以從預約提醒免付費電話號碼傳送回 SMS 的 OTP 訊息。這違反了該號碼的註冊條款，並可能導致電信業者篩選或號碼停用。
為了避免此風險，請針對每個使用案例使用以集區為基礎的傳送與一個集區。當您在`SendTextMessage`請求中指定集區 ID 時，服務只會從該集區中選取起始身分。由於集區中的所有身分都會註冊相同的使用案例，因此後援訊息一律會從適當的號碼傳送。
**傳送方法合規比較**
| 傳送方法 | SMS 備用行為 | 合規風險 |
| --- | --- | --- |
| 以集區為基礎的 （建議） | 回到相同集區中的電話號碼，註冊相同的使用案例 | 低 — 備用號碼符合訊息使用案例 |
| 帳戶層級 | 回到帳戶中任何可用的電話號碼 | 高 — 如果多個使用案例共用帳戶，備用號碼可能與訊息使用案例不符 |
| Direct (AWS RCS 代理程式 ARN) | 無簡訊備用 | 無 — 訊息僅透過 RCS 傳送，或完全不透過 RCS 傳送 |
## 備用邏輯和優先順序
當 AWS 最終使用者傳訊選取訊息的起始身分 （從集區或所有帳戶身分） 時，它會依下列優先順序評估身分：
1. **黏性身分** — 如果目的地電話號碼存在黏性傳送配對，且身分仍然可用，則服務會使用該身分。
1. **AWS RCS 代理**程式 — 如果不存在黏性配對，服務會透過可用的 AWS RCS 代理程式嘗試 RCS 交付。
1. **SMS 短碼** - 如果 RCS 無法使用，服務會選取 SMS 短碼。
1. **SMS 10DLC** — 如果沒有可用的短碼，服務會選取 10DLC 號碼。
1. **SMS 免付費電話號碼** — 如果沒有可用的 10DLC 號碼，服務會選取免付費電話號碼。
1. **SMS 寄件者 ID** — 如果沒有其他身分可用，服務會選取寄件者 ID。
此優先順序適用於您使用的傳送模式範圍內。對於以集區為基礎的傳送，服務只會考慮指定集區中的身分。對於帳戶層級傳送，服務會考慮您帳戶中的所有身分。
### 自動簡訊備用
當您透過集區或在帳戶層級傳送訊息時，如果 RCS 無法交付， AWS 最終使用者傳訊會自動回復為 SMS。備用是非同步的：
如果 AWS 最終使用者傳訊成功提交 RCS 訊息，但未在 25 秒內收到交付確認或失敗訊號，則服務會回復為 SMS。這會處理 RCS 基礎設施接受訊息但交付停滯的情況 （例如，收件人的裝置暫時無法連線、電信業者不支援 RCS，或裝置不支援 RCS)。
**注意**
直接傳送 （指定 AWS RCS 代理程式 ARN 做為起始身分） 不支援自動 SMS 備用。如果您需要簡訊備用，請使用以集區為基礎的傳送。
### 黏性傳送
黏性傳送是一種路由最佳化，可改善交付一致性。當 AWS 最終使用者傳訊成功使用特定原始身分將訊息傳送到目的地電話號碼時，服務會記住該配對 25 小時。在 25 小時時段內傳送至相同目的地的後續訊息會透過相同的起始身分路由，前提是該訊息仍可在集區或帳戶中使用。
黏性傳送適用於 RCS 和 SMS 交付。例如，如果透過 AWS RCS 代理程式透過 RCS 傳遞訊息，則下一個訊息也會在 25 小時內透過相同的代理程式透過 RCS 嘗試傳送至相同的目的地。如果上一則訊息是透過 SMS 傳遞 （在 RCS 退信之後），則會透過相同電話號碼透過 SMS 嘗試下一個訊息。
即使黏性身分是 SMS 電話號碼，服務也會定期重試 RCS 交付。這可確保其裝置獲得 RCS 支援的收件人 （例如，在電信業者推出或裝置升級之後） 在沒有手動介入的情況下開始接收 RCS 訊息。
黏性傳送的關鍵特性：
+ **25 小時 TTL** — 黏性配對會在最後一次成功交付的 25 小時後過期。過期後，服務會重新評估下一個訊息的起始身分優先順序。
+ **自動 RCS 重試** — 即使黏性身分是簡訊電話號碼，服務也會定期嘗試 RCS 交付，以檢查收件人現在是否支援 RCS。
+ **不手動排清** — 您無法手動排清或重設黏性傳送配對。配對會在 25 小時 TTL 後自動過期。
### 後援期間的交付收據
發生簡訊後援時， AWS 最終使用者傳訊會為交付訊息的最終管道產生單一交付收據。如果訊息是在 RCS 退信後透過 SMS 傳遞，則交付接收會指出 SMS 作為交付管道。
在正常情況下， AWS 最終使用者傳訊會在傳送簡訊後援訊息之前撤銷 RCS 訊息。這可防止收件人收到相同的訊息兩次。不過，在極少數情況下，可能會同時傳送 RCS 訊息和 SMS 備用訊息。如果 RCS 訊息在 25 秒逾時之後但在撤銷完成之前傳送，就會發生這種情況。在這些極少數的雙交付案例中，您可能會收到兩個通道的交付收據。
如需雙重交付如何影響帳單的資訊，請參閱 [RCS 計費和定價模型](rcs-billing.md)。
## SMS 後援的帳單影響
當訊息從 RCS 落回 SMS 時，您需要支付 SMS 交付的費用，而不是失敗的 RCS 嘗試。RCS 訊息只有在成功交付到收件人的裝置時才會計費。如果 RCS 交付失敗且訊息降回 SMS，您需為該訊息支付 SMS 費率。
在極少數的雙傳送案例中 （同時傳送 RCS 訊息和簡訊後援訊息），您可能需要支付這兩項傳送的費用。如需完整的帳單詳細資訊，請參閱 [RCS 計費和定價模型](rcs-billing.md)。
## 測試 SMS 備用
您可以測試 SMS 備用行為，以確認在 RCS 無法交付時，您的訊息是透過 SMS 傳遞。測試 SMS 備用的方法有兩種，取決於您是否擁有核准的 SMS 電話號碼。
### 在沒有核准 SMS 號碼的情況下進行測試
您可以驗證 AWS 最終使用者傳訊是否在沒有核准 SMS 電話號碼的情況下正確觸發備用機制。即使沒有核准的號碼，您也可以透過 SMS 看到重試和失敗事件，確認備用是否正常運作。
**在沒有核准 SMS 號碼的情況下測試 SMS 退信**
1. 停用行動資料和 Wi-Fi，或啟用飛行模式，讓您的測試裝置離線。
1. 使用 `SendTextMessage` API 將 RCS 訊息傳送至測試裝置，並將 AWS RCS 代理程式 ARN 做為起始身分。
1. 檢查 CloudWatch 中的訊息事件或您的事件目的地。您應該會看到失敗的交付事件，指出 RCS 交付無法進行，以及服務嘗試簡訊退信。
由於沒有可用於備用的簡訊電話號碼，簡訊交付也會失敗。不過，事件會確認 AWS 最終使用者傳訊已正確觸發備用機制。
### 使用核准的簡訊號碼進行測試
若要進行完整的end-to-end簡訊備用測試，請將核准的簡訊電話號碼和您的 AWS RCS 代理程式新增至相同的電話集區。這可讓您在 RCS 無法使用時，驗證訊息是否透過 SMS 傳遞。
**使用核准的 SMS 號碼測試 SMS 備用**
1. 建立同時包含 AWS RCS 代理程式和已核准簡訊電話號碼 （例如 10DLC、免付費電話或短碼號碼） 的電話集區。
1. 停用行動資料和 Wi-Fi，或啟用飛行模式，讓您的測試裝置離線。
1. 使用 `SendTextMessage` API 以集區 ID 做為起始身分來傳送訊息。
1. 確認訊息是透過 SMS 傳送到您的測試裝置。
1. 檢查傳遞事件，以確認訊息在 RCS 後透過 SMS 管道傳遞。
## 在集區中管理 AWS RCS 代理程式
如需使用 AWS RCS 代理程式建立集區、將代理程式新增至現有集區、了解集區組態需求，以及從集區移除代理程式step-by-step說明，請參閱 [在集區中管理 AWS RCS 代理程式](phone-pool-rcs-agents.md)。