View a markdown version of this page

Solution de repli entre RCS et SMS à l'aide de pools téléphoniques - AWS Messagerie SMS pour l'utilisateur final
Comment la livraison du RCS peut échouerQu'est-ce qui rend possible le repli des SMSPourquoi utiliser les piscinesPool-per-use-case modèleRisque de conformité lié à l'envoi au niveau du compteLogique de repli et ordre de prioritéImplications du recours aux SMS sur la facturationTester la solution de secours par SMSGestion des agents AWS RCS dans des 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 des utilisateurs AWS finaux gère la sélection des canaux pour vous.

Ce chapitre explique comment la distribution RCS peut échouer, ce qui rend possible le repli des SMS, la logique de repli et l'ordre de priorité, ainsi que les implications en matière de facturation. Il décrit également les meilleures pratiques en matière de pool par cas d'utilisation et explique comment ajouter et supprimer des agents AWS RCS des pools. Pour des informations générales sur les pools téléphoniques, consultezLes pools téléphoniques AWS Messagerie SMS pour l'utilisateur final. 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. Comprendre ces modes de défaillance vous permet de planifier votre stratégie de repli :

  • L'opérateur ne prend pas en charge le RCS — L'opérateur de téléphonie 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 antérieur à la version 18).

  • Agent non actif auprès du transporteur  : votre agent AWS RCS n'a pas encore été approuvé par le transporteur du destinataire, ou l'agent a un statut 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 transmis.

Lorsque l'une de ces conditions se produit et que vous utilisez l'envoi basé sur un pool ou au niveau du compte, la messagerie de l'utilisateur AWS final revient automatiquement à la distribution de SMS à l'aide d'un numéro de téléphone dédié ou d'un identifiant d'expéditeur provenant du même pool ou du même compte. Les itinéraires de SMS partagés ne sont pas pris en charge comme solution de rechange pour l'envoi RCS. Si le pool ou le compte ne contient pas d'expéditeur dédié (numéro de téléphone ou identifiant d'expéditeur) valide pour le pays de destination, le message échoue.

Qu'est-ce qui rend possible le repli des SMS

Le recours aux SMS nécessite à la fois un agent AWS RCS et au moins un numéro de téléphone SMS dédié ou un identifiant d'expéditeur dans le même pool. Lorsque vous envoyez un message au pool, la messagerie de l'utilisateur AWS final tente d'abord de le transmettre par RCS. Si la livraison RCS échoue, le service réessaie le message par SMS en utilisant un numéro de téléphone dédié du même pool. Les itinéraires SMS partagés ne sont pas pris en charge pour le repli RCS. Un pool composé uniquement d'un agent AWS RCS (et aucun numéro de téléphone dédié ni identifiant d'expéditeur) ne prend pas en charge le recours aux SMS. Si RCS échoue dans cette configuration, 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 ou identifiants d'expéditeur dédiés aux SMS. Un pool ne comportant qu'un seul type d'identité ne fournit pas de solution de secours cross-canal. Les itinéraires partagés ne sont pas utilisés comme solution de RCS-to-SMS secours, même si les itinéraires partagés sont activés sur le pool.

Pourquoi utiliser les piscines

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

  • Retournement automatique des SMS  : lorsqu'un pool contient à la fois un agent AWS RCS et des numéros de téléphone SMS, la messagerie de l'utilisateur AWS final tente d'abord de transmettre le RCS. Si la livraison RCS échoue (par exemple, si l'appareil du destinataire ou l'opérateur 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 faut livrer via RCS ou 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 les SMS de secours 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 aucun inconvénient, même avec une seule identité d'origine. À titre de solution de RCS-to-SMS repli, 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 qui ont 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 10DLC enregistré pour la messagerie transactionnelle.

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

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

Ce modèle garantit que lorsque la distribution 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 maintenir votre messagerie en conformité avec les exigences de l'opérateur et les 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 ni d'identité d'origine), AWS la messagerie des utilisateurs finaux 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 sur 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

Account-level l'envoi avec des cas d'utilisation mixtes crée un risque de conformité. Par exemple, si votre compte comporte un numéro 10DLC enregistré pour les messages OTP et un numéro gratuit enregistré pour les rappels de rendez-vous, un message OTP reconverti en SMS peut être envoyé depuis le numéro gratuit de rappel de rendez-vous. Cela enfreint les conditions d'enregistrement de ce numéro et peut entraîner le filtrage de l'opérateur 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 de ce pool. Étant donné que toutes les identités du pool sont enregistrées pour le même cas d'utilisation, le message de secours est toujours envoyé depuis un numéro approprié.

Comparaison de la conformité de l'approche d'envoi
Approche d'envoi Comportement de repli des SMS Risque de conformité
Pool-based (recommandé) Revient à un numéro de téléphone du même pool, enregistré pour le même cas d'utilisation Faible : le numéro de secours correspond au cas d'utilisation du message
Account-level Revient à n'importe quel numéro de téléphone dédié ou identifiant d'expéditeur disponible dans le compte. Ne revient pas aux itinéraires partagés. Élevé : le numéro de secours peut ne pas correspondre au cas d'utilisation du message si plusieurs cas d'utilisation partagent le compte
Direct (ARN de l'agent AWS RCS) Pas de solution de repli par SMS Aucun : le message est transmis via RCS uniquement ou pas du tout

Logique de repli et ordre de priorité

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

  1. Identité permanente  : s'il existe un couplage d'envoi permanent 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 fournir 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. Toll-Free Numéro SMS  : 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.

Retournement automatique des 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. Le Fallback est asynchrone :

Si AWS la messagerie des utilisateurs finaux envoie correctement 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 que la livraison est interrompue (par exemple, l'appareil du destinataire est temporairement inaccessible, l'opérateur ne prend pas en charge le RCS ou l'appareil ne l'est pas). RCS-capable

Note

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

Envoi autocollant

L'envoi permanent est une optimisation du routage qui améliore la cohérence des livraisons. Lorsque AWS la messagerie de l'utilisateur final parvient à transmettre 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 vers 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 de Sticky s'applique à la fois au RCS et à la livraison de SMS. Par exemple, si un message est envoyé via RCS via votre agent AWS RCS, le message suivant vers 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é envoyé par SMS (après le repli RCS), le message suivant est tenté par SMS via le même numéro de téléphone.

Le service réessaie périodiquement la livraison RCS, même lorsque l'identité persistante 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 de 25 heures — Le Sticky Pairing 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.

  • Nouvelle tentative automatique du RCS — Même lorsque l'identité persistante est un numéro de téléphone SMS, le service tente régulièrement la livraison 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 persistantes. Le jumelage expire automatiquement après le TTL de 25 heures.

Reçus de livraison pendant la période de repli

En cas de repli des SMS, AWS la messagerie des utilisateurs finaux génère un accusé de réception unique pour le dernier canal qui a délivré le message. Si le message est envoyé par SMS après le repli RCS, le reçu de livraison indique le SMS comme canal de distribution. Vous pouvez déterminer le canal de diffusion en inspectant le originationPhoneNumber champ de l'événement. Si la valeur est un ID d'agent RCS, le message a été transmis via RCS. Si la valeur est un numéro de E.164 téléphone ou un code court, le message a été envoyé par SMS. Pour plus d'informations sur les champs d'événements, consultezExemple AWS Données relatives aux événements de messagerie SMS destinés à l'utilisateur final.

Dans des circonstances normales, AWS la messagerie de l'utilisateur final révoque le message RCS avant que le message de secours ne soit envoyé. Cela empêche le destinataire de recevoir deux fois le même message. Toutefois, dans de rares cas, le message RCS et le message de secours SMS peuvent être envoyé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 la manière dont la double livraison affecte la facturation, consultezModèle de facturation et de tarification RCS.

Implications du recours aux SMS sur la facturation

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

Dans de rares scénarios de double diffusion (où le message RCS et le message de secours SMS sont envoyés à la fois), les deux livraisons peuvent vous être facturées. Pour plus de détails sur la facturation, consultezModèle de facturation et de tarification RCS.

Tester la solution de secours par SMS

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

Tester sans numéro de SMS approuvé

Vous pouvez vérifier que AWS la messagerie de 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 de nouvelle tentative et d'échec par SMS, ce qui confirme que la solution de secours fonctionne.

Pour tester le repli des SMS sans numéro de SMS approuvé

  1. Mettez votre appareil de test hors ligne en désactivant les données mobiles et/ou Wi-Fi 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 le message dans lequel se trouve l'événement 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 revenir en arrière par SMS.

Comme aucun numéro de téléphone SMS n'est disponible pour la solution de secours, l'envoi du SMS échoue également. Cependant, 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 de bout en bout par SMS, 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 le repli des 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/ou Wi-Fi 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é transmis via le canal SMS après le repli RCS.

Gestion des agents AWS RCS dans des pools

Pour obtenir des instructions détaillées sur la création de pools avec les agents AWS RCS, l'ajout d'agents à des 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.