Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Fallback von RCS zu SMS mithilfe von Telefonpools
Ein Telefonpool ist ein Container mit Nachrichtenidentitäten wie AWS RCS-Agenten und SMS-Telefonnummern, der eine Abstraktionsebene zwischen Ihren API-Anfragen und den zugrunde liegenden Ausgangsidentitäten bietet. Pools vereinfachen Konfigurationsänderungen, die Migration von Nummerntypen und das Fallback. RCS-to-SMS Sie senden einen einzelnen API-Aufruf an den Pool, und AWS End User Messaging übernimmt die Kanalauswahl für Sie.
In diesem Kapitel wird erklärt, wie die RCS-Zustellung fehlschlagen kann, warum SMS-Fallback möglich ist, die Fallback-Logik und die Prioritätsreihenfolge sowie die Auswirkungen auf die Abrechnung. Es behandelt auch bewährte Methoden für jeden einzelnen Pool und das Hinzufügen und Entfernen von AWS RCS-Agenten zu Pools. Allgemeine Informationen zu Telefonpools finden Sie unter. Telefonpools in AWS Nachrichtenübermittlung für Endbenutzer Informationen zur Verwaltung von AWS RCS-Agenten finden Sie unterVerwalten von RCS-Agenten.
Topics
Wie die RCS-Lieferung fehlschlagen kann
Die RCS-Lieferung kann aus verschiedenen Gründen fehlschlagen. Das Verständnis dieser Fehlermodi hilft Ihnen bei der Planung Ihrer Fallback-Strategie:
-
Mobilfunkanbieter unterstützt RCS nicht — Der Mobilfunkanbieter des Empfängers hat RCS-Messaging in seinem Netzwerk nicht aktiviert.
-
Gerät unterstützt RCS nicht — Das Gerät des Empfängers ist nicht RCS-fähig (z. B. ein älteres Android-Gerät oder ein iPhone, auf dem iOS vor 18 läuft).
-
Kein Agent beim Mobilfunkanbieter aktiv — Ihr AWS RCS-Agent wurde noch nicht vom Mobilfunkanbieter des Empfängers zugelassen, oder der Agent hat für dieses Land den Status TEILWEISE.
-
Gerät vorübergehend nicht erreichbar — Das Gerät des Empfängers unterstützt RCS, ist aber vorübergehend offline oder hat keine Datenverbindung. RCS-Nachrichten benötigen für die Zustellung eine Datenverbindung.
Wenn eine dieser Bedingungen eintritt und Sie den Versand auf Pool- oder Kontoebene verwenden, wechselt AWS End User Messaging automatisch zur SMS-Zustellung über eine eigene Telefonnummer oder Absender-ID aus demselben Pool oder Konto zurück. Geteilte SMS-Routen werden als Fallback für den RCS-Versand nicht unterstützt. Wenn der Pool oder das Konto keinen eigenen Absender (Telefonnummer oder Absender-ID) enthält, der für das Zielland gültig ist, schlägt die Nachricht fehl.
Was macht SMS-Fallback möglich
Für SMS-Fallback sind sowohl ein AWS RCS-Agent als auch mindestens eine dedizierte SMS-Telefonnummer oder Absender-ID im selben Pool erforderlich. Wenn Sie eine Nachricht an den Pool senden, versucht AWS End User Messaging zuerst die RCS-Zustellung. Wenn die RCS-Zustellung fehlschlägt, versucht der Dienst erneut, die Nachricht per SMS unter einer dedizierten Telefonnummer aus demselben Pool zu senden. Geteilte SMS-Routen werden für den RCS-Fallback nicht unterstützt. Ein Pool, der nur einen AWS RCS-Agenten (und keine dedizierten Telefonnummern oder Absender-IDs) enthält, unterstützt kein SMS-Fallback. Wenn RCS in dieser Konfiguration ausfällt, wird die Nachricht nicht zugestellt.
Wichtig
Damit SMS-Fallback funktioniert, muss Ihr Pool sowohl einen AWS RCS-Agenten als auch eine oder mehrere dedizierte SMS-Telefonnummern oder Absender-IDs enthalten. Ein Pool mit nur einem Identitätstyp bietet kein kanalübergreifendes Fallback. Gemeinsam genutzte Routen werden nicht als RCS-to-SMS Fallback verwendet, auch wenn gemeinsame Routen im Pool aktiviert sind.
Warum Pools verwenden
Wir empfehlen, einen Telefonpool für alle Messaging-Anwendungsfälle zu verwenden, nicht nur für RCS. Pools bieten die folgenden Vorteile:
-
Automatisches SMS-Fallback — Wenn ein Pool sowohl einen AWS RCS-Agenten als auch SMS-Telefonnummern enthält, versucht AWS End User Messaging zuerst die RCS-Zustellung. Wenn die RCS-Zustellung fehlschlägt (z. B. weil das Gerät oder der Netzbetreiber des Empfängers RCS nicht unterstützt), versucht der Service automatisch, die Nachricht per SMS unter Verwendung einer Telefonnummer aus demselben Pool erneut zu senden. Sie müssen keine Fallback-Logik in Ihrer Anwendung implementieren.
-
Intelligentes Routing — Der Service wählt die beste Ausgangsidentität aus dem Pool aus, basierend auf dem Ziel, der Kanalverfügbarkeit und dem festen Sendeverlauf. Dieses Routing erfolgt transparent bei jedem
SendTextMessageAnruf. -
Einzelner API-Aufruf — Sie geben die Pool-ID als Ausgangsidentität in Ihrer
SendTextMessageAnfrage an. Der Dienst bestimmt, ob die Zustellung per RCS oder SMS erfolgt, ohne dass Sie zusätzliche Logik benötigen. -
Flexibilität für zukünftige Änderungen — Sie können jederzeit Telefonnummern und AWS RCS-Agenten zu einem Pool hinzufügen oder daraus entfernen, ohne Ihren Anwendungscode zu ändern. Sie können beispielsweise eine gebührenfreie Nummer für SMS-Fallback hinzufügen oder eine 10DLC-Nummer austauschen, ohne Ihre Versandintegration zu ändern.
-
Keine Kosten oder Nachteile — Für das Erstellen eines Pools und das Hinzufügen von Absenderidentitäten fallen keine zusätzlichen Gebühren an. Selbst mit einer einzigen Telefonnummer oder einem einzelnen AWS RCS-Agenten bietet Ihnen die Verwendung eines Pools die Flexibilität, später ohne Anwendungsänderungen weitere Identitäten hinzuzufügen.
Anmerkung
Wir empfehlen, immer einen Pool für Nachrichten zu verwenden. Die Verwendung eines Pools ist mit keinerlei Kosten oder Nachteilen verbunden, auch nicht mit einer einzigen Ausgangsidentität. Als RCS-to-SMS Fallback muss der Pool sowohl einen AWS RCS-Agenten als auch mindestens eine SMS-Telefonnummer enthalten. Wenn Sie von Anfang an mit einem Pool beginnen, können Sie später SMS-Fallback-Nummern oder zusätzliche AWS RCS-Agenten hinzufügen, ohne Ihren Sendecode zu ändern.
Pool-per-use-case Modell
Wir empfehlen, einen Pool pro Anwendungsfall zu erstellen. Jeder Pool sollte alle Telefonnummern und den AWS RCS-Agenten enthalten, die einem einzigen Messaging-Zweck dienen. Beispiel:
-
Ein Transaktionspool für OTP-Codes und Kontobenachrichtigungen, der Ihren AWS RCS-Agenten und eine 10DLC-Nummer enthält, die für Transaktionsnachrichten registriert ist.
-
Ein Marketingpool für Werbebotschaften, der denselben AWS RCS-Agenten (oder einen anderen) und eine für Marketingzwecke registrierte gebührenfreie Nummer enthält.
-
Ein Pool an Terminerinnerungen für die Planung von Benachrichtigungen, der Ihren AWS RCS-Agenten und eine spezielle Telefonnummer für terminbezogene Nachrichten enthält.
Dieses Modell stellt sicher, dass, wenn die RCS-Zustellung fehlschlägt und der Service auf SMS zurückgreift, die Ersatznachricht von einer Telefonnummer gesendet wird, die für denselben Anwendungsfall registriert und zugelassen ist. Dadurch wird gewährleistet, dass Ihre Nachrichten den Anforderungen des Mobilfunkanbieters und den Registrierungsbedingungen entsprechen.
Beim Senden auf Kontoebene besteht ein Compliance-Risiko
Wenn Sie Nachrichten auf Kontoebene senden (ohne einen Pool oder eine Herkunftsidentität anzugeben), wählt AWS End User Messaging eine Absenderidentität aus allen verfügbaren Identitäten in Ihrem Konto aus. Wenn in Ihrem Konto mehrere Telefonnummern für unterschiedliche Anwendungsfälle registriert sind, wählt der Dienst möglicherweise eine Telefonnummer aus, die nicht mit dem Inhalt Ihrer Nachricht übereinstimmt.
Wichtig
Account-level Das Senden mit gemischten Anwendungsfällen birgt ein Compliance-Risiko. Wenn in Ihrem Konto beispielsweise eine 10DLC-Nummer für OTP-Nachrichten registriert ist und eine gebührenfreie Nummer für Terminerinnerungen registriert ist, könnte eine OTP-Nachricht, die auf SMS zurückgreift, von der gebührenfreien Nummer für Terminerinnerungen gesendet werden. Dies verstößt gegen die Registrierungsbedingungen für diese Nummer und kann zur Filterung des Mobilfunkanbieters oder zur Sperrung der Nummer führen.
Um dieses Risiko zu vermeiden, verwenden Sie poolbasiertes Senden mit einem Pool pro Anwendungsfall. Wenn Sie in Ihrer SendTextMessage Anfrage eine Pool-ID angeben, wählt der Dienst nur Ausgangsidentitäten aus diesem Pool aus. Da alle Identitäten im Pool für denselben Anwendungsfall registriert sind, wird die Fallback-Nachricht immer von einer entsprechenden Nummer gesendet.
| Ansatz wird gesendet | SMS-Fallback-Verhalten | Risiko der Einhaltung von Vorschriften |
|---|---|---|
| Pool-based (empfohlen) | Fällt auf eine Telefonnummer im gleichen Pool zurück, die für denselben Anwendungsfall registriert ist | Niedrig — die Fallback-Nummer entspricht dem Anwendungsfall der Nachricht |
| Account-level | Greift auf jede verfügbare dedizierte Telefonnummer oder Absender-ID im Konto zurück. Greift nicht auf gemeinsam genutzte Routen zurück. | Hoch — Die Fallback-Nummer entspricht möglicherweise nicht dem Anwendungsfall der Nachricht, wenn mehrere Anwendungsfälle das Konto gemeinsam nutzen |
| Direkt (AWS RCS Agent ARN) | Kein SMS-Fallback | Keine — die Nachricht wird nur über RCS oder gar nicht zugestellt |
Fallback-Logik und Prioritätsreihenfolge
Wenn AWS End User Messaging eine Ausgangsidentität für eine Nachricht auswählt (entweder aus einem Pool oder aus allen Kontenidentitäten), bewertet es Identitäten in der folgenden Prioritätsreihenfolge:
-
Dauerhafte Identität — Wenn für die Zieltelefonnummer eine feste Sendekopplung existiert und die Identität immer noch verfügbar ist, verwendet der Dienst diese Identität.
-
AWS RCS Agent — Wenn keine feste Kopplung existiert, versucht der Service, die RCS-Zustellung über einen verfügbaren AWS RCS-Agenten durchzuführen.
-
SMS-Kurzcode — Wenn RCS nicht verfügbar ist, wählt der Service einen SMS-Kurzcode aus.
-
SMS 10DLC — Wenn kein Kurzcode verfügbar ist, wählt der Dienst eine 10DLC-Nummer aus.
-
Toll-Free SMS-Nummer — Wenn keine 10DLC-Nummer verfügbar ist, wählt der Dienst eine gebührenfreie Nummer aus.
-
SMS-Absender-ID — Wenn keine andere Identität verfügbar ist, wählt der Dienst eine Absender-ID aus.
Diese Prioritätsreihenfolge gilt im Rahmen des von Ihnen verwendeten Sendemusters. Beim poolbasierten Senden berücksichtigt der Dienst nur Identitäten im angegebenen Pool. Beim Senden auf Kontoebene berücksichtigt der Dienst alle Identitäten in Ihrem Konto.
Automatischer SMS-Fallback
Wenn Sie eine Nachricht über einen Pool oder auf Kontoebene senden, fällt AWS End User Messaging automatisch auf SMS zurück, wenn die RCS-Zustellung nicht möglich ist. Das Fallback ist asynchron:
Wenn AWS End User Messaging die RCS-Nachricht erfolgreich übermittelt, aber nicht innerhalb von 25 Sekunden eine Empfangsbestätigung oder ein Fehlersignal erhält, greift der Dienst auf SMS zurück. Dies behandelt Fälle, in denen die RCS-Infrastruktur die Nachricht akzeptiert, die Zustellung jedoch unterbrochen wird (z. B. wenn das Gerät des Empfängers vorübergehend nicht erreichbar ist, der Netzbetreiber RCS nicht unterstützt oder das Gerät nicht). RCS-capable
Anmerkung
Direktes Senden (unter Angabe eines AWS RCS Agent-ARN als Ausgangsidentität) unterstützt kein automatisches SMS-Fallback. Wenn Sie ein SMS-Fallback benötigen, verwenden Sie das poolbasierte Senden.
Dauerhafter Versand
Sticky Sending ist eine Routing-Optimierung, die die Konsistenz der Zustellung verbessert. Wenn AWS End User Messaging unter Verwendung einer bestimmten Absenderidentität erfolgreich eine Nachricht an eine Zieltelefonnummer übermittelt, merkt sich der Dienst diese Verbindung 25 Stunden lang. Nachfolgende Nachrichten an dasselbe Ziel innerhalb des 25-Stunden-Fensters werden über dieselbe Absenderidentität weitergeleitet, sofern sie noch im Pool oder Konto verfügbar ist.
Dauerhaftes Senden gilt sowohl für die RCS- als auch für die SMS-Zustellung. Wenn beispielsweise eine Nachricht über RCS über Ihren AWS RCS Agenten zugestellt wird, wird auch versucht, innerhalb von 25 Stunden die nächste Nachricht an dasselbe Ziel über RCS über denselben Agenten zu senden. Wenn die vorherige Nachricht per SMS zugestellt wurde (nach dem RCS-Fallback), wird versucht, die nächste Nachricht per SMS über dieselbe Telefonnummer zu senden.
Der Dienst versucht in regelmäßigen Abständen, die RCS-Zustellung zu wiederholen, auch wenn es sich bei der festen Identität um eine SMS-Telefonnummer handelt. Dadurch wird sichergestellt, dass Empfänger, deren Geräte RCS-Unterstützung erhalten (z. B. nach einer Netzbetreibereinführung oder einem Geräteupgrade), ohne manuelles Eingreifen RCS-Nachrichten empfangen.
Hauptmerkmale des Sticky-Sendens:
-
25-Stunden-TTL — Das Sticky-Pairing läuft 25 Stunden nach der letzten erfolgreichen Zustellung ab. Nach Ablauf bewertet der Dienst die Prioritätsreihenfolge der Absenderidentität für die nächste Nachricht erneut.
-
Automatischer RCS-Wiederholungsversuch — Auch wenn es sich bei der festen Identität um eine SMS-Telefonnummer handelt, versucht der Dienst in regelmäßigen Abständen, die RCS-Zustellung durchzuführen, um zu überprüfen, ob der Empfänger RCS jetzt unterstützt.
-
Kein manuelles Leeren — Sie können feste Sendepaare nicht manuell löschen oder zurücksetzen. Das Pairing läuft nach Ablauf der 25-stündigen TTL automatisch ab.
Empfangsbelege während des Fallbacks
Beim SMS-Fallback generiert AWS End User Messaging eine einzige Empfangsbestätigung für den letzten Kanal, über den die Nachricht zugestellt wurde. Wenn die Nachricht nach dem RCS-Fallback per SMS zugestellt wird, wird auf der Empfangsbestätigung SMS als Übermittlungskanal angegeben. Sie können den Zustellungskanal ermitteln, indem Sie das originationPhoneNumber Feld in der Veranstaltung überprüfen. Wenn der Wert eine RCS-Agenten-ID ist, wurde die Nachricht über RCS zugestellt. Handelt es sich bei dem Wert um eine E.164 Telefonnummer oder einen Kurzcode, wurde die Nachricht per SMS zugestellt. Weitere Informationen zu Ereignisfeldern finden Sie unterBeispiel AWS SMS-Ereignisdaten für Endbenutzer-Nachrichten.
Unter normalen Umständen widerruft AWS End User Messaging die RCS-Nachricht, bevor die SMS-Ersatznachricht zugestellt wird. Dadurch wird verhindert, dass der Empfänger dieselbe Nachricht zweimal erhält. In seltenen Fällen können jedoch sowohl die RCS-Nachricht als auch die SMS-Ersatznachricht zugestellt werden. Dies kann passieren, wenn die RCS-Nachricht nach dem Timeout von 25 Sekunden, aber bevor der Widerruf abgeschlossen ist, zugestellt wird. In diesen seltenen Szenarien mit doppelter Zustellung erhalten Sie möglicherweise Empfangsbestätigungen für beide Kanäle.
Informationen darüber, wie sich die doppelte Zustellung auf die Rechnungsstellung auswirkt, finden Sie unter. RCS-Abrechnungs- und Preismodell
Auswirkungen des SMS-Fallbacks auf die Abrechnung
Wenn eine Nachricht von RCS auf SMS zurückfällt, wird Ihnen die SMS-Zustellung in Rechnung gestellt, nicht der fehlgeschlagene RCS-Versuch. RCS-Nachrichten werden nur in Rechnung gestellt, wenn sie erfolgreich an das Gerät des Empfängers übermittelt wurden. Wenn die RCS-Zustellung fehlschlägt und die Nachricht auf SMS zurückfällt, zahlen Sie den SMS-Tarif für diese Nachricht.
In seltenen Szenarien mit doppelter Zustellung (in denen sowohl die RCS-Nachricht als auch die SMS-Ersatznachricht zugestellt werden), können Ihnen beide Zustellungen in Rechnung gestellt werden. Vollständige Rechnungsdetails finden Sie unter. RCS-Abrechnungs- und Preismodell
SMS-Fallback wird getestet
Sie können das SMS-Fallback-Verhalten testen, um sicherzustellen, dass Ihre Nachrichten per SMS zugestellt werden, wenn die RCS-Zustellung nicht möglich ist. Es gibt zwei Methoden, um das SMS-Fallback zu testen, je nachdem, ob Sie eine genehmigte SMS-Telefonnummer haben.
Testen ohne eine genehmigte SMS-Nummer
Sie können überprüfen, ob AWS End User Messaging den Fallback-Mechanismus ohne eine genehmigte SMS-Telefonnummer korrekt auslöst. Auch ohne eine genehmigte Nummer können Sie sich die Wiederholungs- und Fehlerereignisse per SMS ansehen, wodurch bestätigt wird, dass das Fallback funktioniert.
Um das SMS-Fallback ohne eine genehmigte SMS-Nummer zu testen
-
Schalten Sie Ihr Testgerät offline, indem Sie mobile Daten deaktivieren und/oder Wi-Fi den Flugzeugmodus aktivieren.
-
Senden Sie mithilfe der
SendTextMessageAPI eine RCS-Nachricht mit Ihrem AWS RCS Agent-ARN als Ausgangsidentität an das Testgerät. -
Überprüfen Sie das Nachrichtenereignis in CloudWatch oder Ihr Veranstaltungsziel. Es sollte ein Ereignis mit fehlgeschlagener Zustellung angezeigt werden, das darauf hinweist, dass die RCS-Zustellung nicht möglich war und dass der Dienst versucht hat, ein SMS-Fallback durchzuführen.
Da keine SMS-Telefonnummer als Fallback verfügbar ist, schlägt auch die SMS-Zustellung fehl. Das Ereignis bestätigt jedoch, dass AWS End User Messaging den Fallback-Mechanismus korrekt ausgelöst hat.
Test mit einer genehmigten SMS-Nummer
Für einen vollständigen SMS-Fallback-Test von Anfang bis Ende fügen Sie eine genehmigte SMS-Telefonnummer und Ihren AWS RCS-Agenten demselben Telefonpool hinzu. Auf diese Weise können Sie überprüfen, ob Nachrichten per SMS zugestellt werden, wenn RCS nicht verfügbar ist.
Um das SMS-Fallback mit einer genehmigten SMS-Nummer zu testen
-
Erstellen Sie einen Telefonpool, der sowohl Ihren AWS RCS-Agenten als auch eine genehmigte SMS-Telefonnummer (z. B. eine 10DLC-, gebührenfreie Nummer oder eine Kurzwahlnummer) enthält.
-
Schalten Sie Ihr Testgerät offline, indem Sie mobile Daten deaktivieren und/oder den Flugzeugmodus Wi-Fi aktivieren.
-
Senden Sie mithilfe der
SendTextMessageAPI eine Nachricht mit der Pool-ID als Ausgangsidentität. -
Stellen Sie sicher, dass die Nachricht per SMS an Ihr Testgerät gesendet wird.
-
Überprüfen Sie das Zustellungsereignis, um zu bestätigen, dass die Nachricht nach dem RCS-Fallback über den SMS-Kanal zugestellt wurde.
Verwaltung von AWS RCS-Agenten in Pools
Eine schrittweise Anleitung zum Erstellen von Pools mit AWS RCS-Agenten, zum Hinzufügen von Agenten zu vorhandenen Pools, zum Verständnis der Poolkonfigurationsanforderungen und zum Entfernen von Agenten aus Pools finden Sie unter. Verwaltung von AWS RCS-Agenten in Pools
