View a markdown version of this page

Solution de repli entre RCS et SMS à l'aide de pools téléphoniques - AWS Messagerie SMS à l'utilisateur final
Comment la livraison du RCS peut échouerQu'est-ce qui rend possible le repli sur les SMSPourquoi utiliser des piscinesPool-per-use-case modèleRisque de conformité lié à l'envoi au niveau du compteLogique de repli et ordre de prioritéImplications de la solution de remplacement des SMS sur la facturationTester la solution de secours par SMSGestion des agents AWS RCS dans les pools

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Solution de repli entre RCS et SMS à l'aide de pools téléphoniques

Un pool téléphonique est un conteneur d'identités de messagerie, telles que les agents AWS RCS et les numéros de téléphone SMS, qui fournit une couche d'abstraction entre vos demandes d'API et les identités d'origine sous-jacentes. Les pools simplifient les modifications de configuration, la migration des types de numéros et les solutions de RCS-to-SMS secours. Vous envoyez un seul appel d'API au pool, et la messagerie utilisateur AWS final s'occupe de la sélection des canaux pour vous.

Ce chapitre explique comment la livraison du RCS peut échouer, ce qui rend possible le remplacement par SMS, la logique de repli et l'ordre de priorité, ainsi que les implications en matière de facturation. Il décrit également les pool-per-use-case meilleures pratiques et explique comment ajouter et supprimer des agents AWS RCS dans les pools. Pour obtenir des informations générales sur les pools de téléphones, consultezPools téléphoniques dans les messages SMS destinés aux utilisateurs AWS finaux. Pour plus d'informations sur la gestion des agents AWS RCS, consultezGestion des agents RCS.

Comment la livraison du RCS peut échouer

La livraison du RCS peut échouer pour plusieurs raisons. La compréhension de ces modes de défaillance vous aide à planifier votre stratégie de repli :

  • L'opérateur ne prend pas en charge le RCS : l'opérateur mobile du destinataire n'a pas activé la messagerie RCS sur son réseau.

  • L'appareil ne prend pas en charge le RCS : l'appareil du destinataire ne dispose pas de la fonctionnalité RCS (par exemple, un ancien appareil Android ou un iPhone exécutant iOS avant la version 18).

  • Agent non actif chez le transporteur : votre agent AWS RCS n'a pas encore été approuvé par le transporteur du destinataire, ou le statut de l'agent est PARTIEL pour ce pays.

  • Appareil temporairement inaccessible — L'appareil du destinataire prend en charge le RCS mais est temporairement hors ligne ou n'a aucune connexion de données. Les messages RCS nécessitent une connexion de données pour être envoyés.

Lorsque l'une de ces conditions se produit et que vous utilisez l'envoi basé sur un pool ou au niveau du compte, AWS la messagerie à l'utilisateur final revient automatiquement à la livraison de SMS en utilisant un numéro de téléphone du même pool ou du même compte.

Qu'est-ce qui rend possible le repli sur les SMS

La solution de secours par SMS nécessite à la fois un agent AWS RCS et au moins un numéro de téléphone SMS dans le même pool. Lorsque vous envoyez un message au pool, AWS End User Messaging tente d'abord de le transmettre au RCS. Si la livraison du RCS échoue, le service réessaie le message par SMS en utilisant un numéro de téléphone du même pool. Un pool ne comportant qu'un agent AWS RCS (et aucun numéro de téléphone) ne prend pas en charge le remplacement par SMS. En cas d'échec du RCS, le message n'est pas délivré.

Important

Pour que la solution de secours par SMS fonctionne, votre pool doit contenir à la fois un agent AWS RCS et un ou plusieurs numéros de téléphone SMS. Un pool ne comportant qu'un seul type d'identité ne fournit pas de solution de secours intercanal.

Pourquoi utiliser des piscines

Nous recommandons d'utiliser un pool téléphonique pour tous les cas d'utilisation de la messagerie, et pas seulement pour le RCS. Les piscines offrent les avantages suivants :

  • Solution de secours automatique par SMS : lorsqu'un pool contient à la fois un agent AWS RCS et des numéros de téléphone SMS, la messagerie à l'utilisateur AWS final tente d'abord de transmettre le RCS. Si la livraison du RCS échoue (par exemple, si l'appareil ou l'opérateur du destinataire ne prend pas en charge le RCS), le service réessaie automatiquement le message par SMS en utilisant un numéro de téléphone du même pool. Il n'est pas nécessaire d'implémenter une logique de repli dans votre application.

  • Routage intelligent : le service sélectionne la meilleure identité d'origine dans le pool en fonction de la destination, de la disponibilité des canaux et de l'historique des envois. Ce routage s'effectue de manière transparente à chaque SendTextMessage appel.

  • Appel d'API unique : vous spécifiez l'ID du pool comme identité d'origine dans votre SendTextMessage demande. Le service détermine s'il convient de livrer par RCS ou par SMS sans aucune logique supplémentaire de votre part.

  • Flexibilité pour les modifications futures : vous pouvez ajouter ou supprimer des numéros de téléphone et des agents AWS RCS d'un pool à tout moment sans modifier le code de votre application. Par exemple, vous pouvez ajouter un numéro gratuit pour le remplacement des SMS ou échanger un numéro 10DLC sans modifier votre intégration d'envoi.

  • Aucun coût ni inconvénient : la création d'un pool et l'ajout d'identités d'origine à celui-ci n'entraînent aucun frais supplémentaire. Même avec un seul numéro de téléphone ou un seul agent AWS RCS, l'utilisation d'un pool vous donne la possibilité d'ajouter d'autres identités ultérieurement sans modifier l'application.

Note

Nous vous recommandons de toujours utiliser un pool pour la messagerie. L'utilisation d'un pool ne présente aucun coût ni inconvénient, même avec une seule identité d'origine. Pour le RCS-to-SMS remplacement, le pool doit contenir à la fois un agent AWS RCS et au moins un numéro de téléphone SMS. En commençant par un pool depuis le début, vous pouvez ajouter des numéros de secours par SMS ou des agents AWS RCS supplémentaires ultérieurement sans modifier votre code d'envoi.

Pool-per-use-case modèle

Nous vous recommandons de créer un pool par cas d'utilisation. Chaque pool doit contenir tous les numéros de téléphone et l'agent AWS RCS destinés à un seul objectif de messagerie. Par exemple :

  • Un pool transactionnel pour les codes OTP et les notifications de compte, contenant votre agent AWS RCS et un numéro de 10 DLC enregistré pour la messagerie transactionnelle.

  • Un pool marketing pour les messages promotionnels, contenant le même agent AWS RCS (ou un autre) et un numéro gratuit enregistré pour le marketing.

  • Un pool de rappels de rendez-vous pour planifier les notifications, contenant votre agent AWS RCS et un numéro de téléphone dédié pour les messages liés aux rendez-vous.

Ce modèle garantit que lorsque la livraison du RCS échoue et que le service revient aux SMS, le message de secours est envoyé à partir d'un numéro de téléphone enregistré et approuvé pour le même cas d'utilisation. Cela permet de garantir la conformité de votre messagerie aux exigences du transporteur et aux conditions d'enregistrement.

Risque de conformité lié à l'envoi au niveau du compte

Lorsque vous envoyez des messages au niveau du compte (sans spécifier de pool ou d'identité d'origine), AWS la messagerie utilisateur final sélectionne une identité d'origine parmi toutes les identités disponibles dans votre compte. Si plusieurs numéros de téléphone sont enregistrés dans votre compte pour différents cas d'utilisation, le service peut sélectionner un numéro de téléphone qui ne correspond pas au contenu de votre message.

Important

L'envoi au niveau du compte avec des cas d'utilisation mixtes crée un risque de conformité. Par exemple, si votre compte possède un numéro 10DLC enregistré pour les messages OTP et un numéro gratuit enregistré pour les rappels de rendez-vous, un message OTP qui revient à un SMS peut être envoyé à partir du numéro gratuit de rappel de rendez-vous. Cela enfreint les conditions d'enregistrement de ce numéro et peut entraîner le filtrage du transporteur ou la suspension du numéro.

Pour éviter ce risque, utilisez l'envoi basé sur un pool avec un pool par cas d'utilisation. Lorsque vous spécifiez un ID de pool dans votre SendTextMessage demande, le service sélectionne uniquement les identités d'origine à partir de ce pool. Comme toutes les identités du pool sont enregistrées pour le même cas d'utilisation, le message de secours est toujours envoyé à partir d'un numéro approprié.

Comparaison de la conformité de l'approche d'envoi
Approche d'envoi Comportement de secours des SMS Risque de conformité
Basé sur la piscine (recommandé) Revient à un numéro de téléphone du même pool, enregistré pour le même cas d'utilisation Faible : le nombre de remplacement correspond au cas d'utilisation du message
Au niveau du compte Revient à n'importe quel numéro de téléphone disponible dans le compte Élevé : le numéro de remplacement peut ne pas correspondre au cas d'utilisation du message si plusieurs cas d'utilisation partagent le même compte
Direct (ARN de l'agent AWS RCS) Aucune solution de secours par SMS Aucun — le message est délivré via RCS uniquement ou pas du tout

Logique de repli et ordre de priorité

Lorsque AWS la messagerie de l'utilisateur final sélectionne une identité d'origine pour un message (provenant d'un pool ou de toutes les identités de compte), elle évalue les identités dans l'ordre de priorité suivant :

  1. Identité permanente : si un jumelage d'envoi permanent existe pour le numéro de téléphone de destination et que l'identité est toujours disponible, le service utilise cette identité.

  2. Agent AWS RCS : s'il n'existe aucun couplage permanent, le service tente de livrer le RCS via un agent AWS RCS disponible.

  3. Code court SMS — Si le RCS n'est pas disponible, le service sélectionne un code court SMS.

  4. SMS 10DLC — Si aucun code court n'est disponible, le service sélectionne un numéro 10DLC.

  5. Numéro SMS gratuit — Si aucun numéro 10DLC n'est disponible, le service sélectionne un numéro gratuit.

  6. ID de l'expéditeur du SMS : si aucune autre identité n'est disponible, le service sélectionne un identifiant d'expéditeur.

Cet ordre de priorité s'applique dans le cadre du modèle d'envoi que vous utilisez. Pour l'envoi basé sur un pool, le service ne prend en compte que les identités du pool spécifié. Pour les envois au niveau du compte, le service prend en compte toutes les identités de votre compte.

Solution de secours automatique par SMS

Lorsque vous envoyez un message via un pool ou au niveau du compte, la messagerie de l'utilisateur AWS final revient automatiquement aux SMS si la livraison RCS n'est pas possible. Fallback est asynchrone :

Si AWS la messagerie utilisateur final envoie avec succès le message RCS mais ne reçoit pas de confirmation de livraison ou de signal d'échec dans les 25 secondes, le service revient aux SMS. Cela permet de gérer les cas où l'infrastructure RCS accepte le message mais où la livraison s'arrête (par exemple, l'appareil du destinataire est temporairement injoignable, le transporteur ne prend pas en charge le RCS ou l'appareil n'est pas compatible RCS).

Note

L'envoi direct (en spécifiant un ARN d'agent AWS RCS comme identité d'origine) ne prend pas en charge le repli automatique des SMS. Si vous avez besoin d'une solution de secours par SMS, utilisez l'envoi basé sur le pool.

Envoi permanent

L'envoi permanent est une optimisation du routage qui améliore la cohérence des livraisons. Lorsque AWS la messagerie de l'utilisateur final envoie avec succès un message à un numéro de téléphone de destination en utilisant une identité d'origine spécifique, le service mémorise ce jumelage pendant 25 heures. Les messages suivants envoyés à la même destination dans le délai de 25 heures sont acheminés via la même identité d'origine, à condition qu'elle soit toujours disponible dans le pool ou le compte.

L'envoi permanent s'applique à la fois au RCS et à l'envoi de SMS. Par exemple, si un message est délivré via RCS via votre agent AWS RCS, le message suivant envoyé à la même destination dans les 25 heures est également tenté via RCS via le même agent. Si le message précédent a été délivré par SMS (après le repli du RCS), le message suivant est tenté par SMS via le même numéro de téléphone.

Le service réessaie régulièrement de livrer le RCS, même si l'identifiant permanent est un numéro de téléphone SMS. Cela garantit que les destinataires dont les appareils bénéficient du support RCS (par exemple, après le déploiement d'un opérateur ou une mise à niveau de l'appareil) commencent à recevoir des messages RCS sans intervention manuelle.

Principales caractéristiques du Sticky Sending :

  • TTL dans les 25 heures — L'accord autocollant expire 25 heures après la dernière livraison réussie. Après expiration, le service réévalue l'ordre de priorité de l'identité d'origine pour le message suivant.

  • Réessai automatique du RCS — Même lorsque l'identité permanente est un numéro de téléphone SMS, le service tente régulièrement de délivrer le RCS pour vérifier si le destinataire prend désormais en charge le RCS.

  • Pas de rinçage manuel : vous ne pouvez pas vider ou réinitialiser manuellement les paires d'envoi autocollantes. Le jumelage expire automatiquement après le délai TTL de 25 heures.

Reçus de livraison lors du repli

Lorsque le remplacement par SMS se produit, AWS la messagerie de l'utilisateur final génère un accusé de réception unique pour le canal final qui a transmis le message. Si le message est délivré par SMS après le repli du RCS, le reçu de livraison indique que le SMS est le canal de livraison.

Dans des circonstances normales, AWS la messagerie utilisateur final révoque le message RCS avant que le message de secours SMS ne soit délivré. Cela empêche le destinataire de recevoir deux fois le même message. Cependant, dans de rares cas, le message RCS et le message de secours SMS peuvent être délivrés. Cela peut se produire si le message RCS est délivré après le délai de 25 secondes mais avant la fin de la révocation. Dans ces rares scénarios de double livraison, vous pouvez recevoir des reçus de livraison pour les deux canaux.

Pour plus d'informations sur l'impact de la double livraison sur la facturation, consultezModèle de facturation et de tarification RCS.

Implications de la solution de remplacement des SMS sur la facturation

Lorsqu'un message passe du RCS au SMS, vous êtes facturé pour la livraison du SMS, et non pour l'échec de la tentative de RCS. Les messages RCS ne sont facturés que s'ils sont livrés avec succès à l'appareil du destinataire. Si la livraison du RCS échoue et que le message revient au format SMS, vous payez le tarif SMS correspondant à ce message.

Dans de rares scénarios de double livraison (dans lesquels le message RCS et le message de secours SMS sont délivrés à la fois), les deux livraisons peuvent vous être facturées. Pour obtenir tous les détails de facturation, consultezModèle de facturation et de tarification RCS.

Tester la solution de secours par SMS

Vous pouvez tester le comportement de secours des SMS pour vérifier que vos messages sont délivrés par SMS lorsque la livraison RCS n'est pas possible. Il existe deux approches pour tester la solution de secours par SMS, selon que vous disposez ou non d'un numéro de téléphone SMS approuvé.

Test sans numéro de SMS approuvé

Vous pouvez vérifier que AWS la messagerie à l'utilisateur final déclenche correctement le mécanisme de secours sans numéro de téléphone SMS approuvé. Même sans numéro approuvé, vous pouvez voir les événements relatifs aux nouvelles tentatives et aux échecs par SMS, ce qui confirme que la solution de secours fonctionne.

Pour tester la solution de secours par SMS sans numéro de SMS approuvé

  1. Mettez votre appareil de test hors ligne en désactivant les données mobiles et le Wi-Fi, ou en activant le mode avion.

  2. Envoyez un message RCS à l'appareil de test à l'aide de l'SendTextMessageAPI avec l'ARN de votre agent AWS RCS comme identité d'origine.

  3. Vérifiez l'événement du message CloudWatch ou la destination de votre événement. Vous devriez voir un événement d'échec de livraison indiquant que la livraison RCS n'a pas été possible et que le service a tenté de remplacer les SMS.

Comme aucun numéro de téléphone SMS n'est disponible pour le remplacement, la livraison du SMS échoue également. Toutefois, l'événement confirme que la messagerie de l'utilisateur AWS final a correctement déclenché le mécanisme de secours.

Test avec un numéro de SMS approuvé

Pour un test de secours complet end-to-end, ajoutez un numéro de téléphone SMS approuvé et votre agent AWS RCS au même pool téléphonique. Cela vous permet de vérifier que les messages sont envoyés par SMS lorsque le RCS n'est pas disponible.

Pour tester la solution de secours par SMS avec un numéro de SMS approuvé

  1. Créez un pool téléphonique contenant à la fois votre agent AWS RCS et un numéro de téléphone SMS approuvé (tel qu'un numéro 10DLC, un numéro gratuit ou un numéro abrégé).

  2. Mettez votre appareil de test hors ligne en désactivant les données mobiles et le Wi-Fi, ou en activant le mode avion.

  3. Envoyez un message à l'aide de l'SendTextMessageAPI avec l'ID du pool comme identité d'origine.

  4. Vérifiez que le message est envoyé par SMS à votre appareil de test.

  5. Vérifiez l'événement de livraison pour confirmer que le message a été délivré via le canal SMS après le repli du RCS.

Gestion des agents AWS RCS dans les pools

Pour step-by-step obtenir des instructions sur la création de pools avec les agents AWS RCS, l'ajout d'agents aux pools existants, la compréhension des exigences de configuration des pools et la suppression d'agents des pools, consultezGestion des agents AWS RCS dans les pools.