As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Substituição de RCS para SMS usando grupos telefônicos
Um pool telefônico é um contêiner de identidades de mensagens, como agentes do AWS RCS e números de telefone SMS, que fornece uma camada de abstração entre suas solicitações de API e as identidades de origem subjacentes. Os pools simplificam as alterações de configuração, a migração de tipos de números e o RCS-to-SMS fallback. Você envia uma única chamada de API para o pool e o AWS End User Messaging gerencia a seleção de canais para você.
Este capítulo explica como a entrega do RCS pode falhar, o que torna possível o fallback do SMS, a lógica de fallback, a ordem de prioridade e as implicações no faturamento. Ele também aborda as melhores práticas de pool por caso de uso e como adicionar e remover agentes do AWS RCS dos pools. Para obter informações gerais sobre grupos telefônicos, consultePools telefônicos em AWS Mensagens SMS para o usuário final. Para obter informações sobre o gerenciamento de agentes do AWS RCS, consulteGerenciar agentes RCS.
Tópicos
Como a entrega do RCS pode falhar
A entrega do RCS pode falhar por vários motivos. Entender esses modos de falha ajuda você a planejar sua estratégia alternativa:
-
A operadora não oferece suporte a RCS — A operadora móvel do destinatário não habilitou o envio de mensagens RCS em sua rede.
-
O dispositivo não suporta RCS — O dispositivo do destinatário não tem capacidade de RCS (por exemplo, um dispositivo Android mais antigo ou um iPhone com iOS anterior a 18 anos).
-
Agente não ativo na transportadora — Seu agente do AWS RCS ainda não foi aprovado pela transportadora do destinatário, ou o agente está com status PARCIAL naquele país.
-
Dispositivo temporariamente inacessível — O dispositivo do destinatário suporta RCS, mas está temporariamente offline ou não tem conexão de dados. As mensagens RCS exigem uma conexão de dados para entrega.
Quando qualquer uma dessas condições ocorre e você está usando o envio baseado em pool ou em nível de conta, as mensagens do usuário AWS final retornam automaticamente à entrega de SMS usando um número de telefone dedicado ou ID de remetente do mesmo pool ou conta. As rotas de SMS compartilhadas não são suportadas como alternativa para o envio de RCS. Se o pool ou a conta não contiverem um remetente dedicado (número de telefone ou ID do remetente) válido para o país de destino, a mensagem falhará.
O que torna possível o recurso de SMS
O SMS fallback exige um agente do AWS RCS e pelo menos um número de telefone SMS dedicado ou ID de remetente no mesmo pool. Quando você envia uma mensagem para o pool, o AWS End User Messaging tenta primeiro a entrega do RCS. Se a entrega do RCS falhar, o serviço repetirá a mensagem via SMS usando um número de telefone dedicado do mesmo pool. As rotas de SMS compartilhadas não são suportadas pelo RCS fallback. Um pool com apenas um agente do AWS RCS (e sem números de telefone ou IDs de remetente dedicados) não oferece suporte ao recurso de SMS. Se o RCS falhar nessa configuração, a mensagem não será entregue.
Importante
Para que o SMS fallback funcione, seu pool deve conter um agente do AWS RCS e um ou mais números de telefone SMS ou IDs de remetente dedicados. Um pool com apenas um único tipo de identidade não fornece fallback entre canais. As rotas compartilhadas não são usadas como RCS-to-SMS alternativa, mesmo que as rotas compartilhadas estejam habilitadas no pool.
Por que usar piscinas
Recomendamos usar um pool telefônico para todos os casos de uso de mensagens, não apenas para o RCS. As piscinas oferecem as seguintes vantagens:
-
Recurso automático de SMS — Quando um pool contém um agente do AWS RCS e números de telefone SMS, o sistema de mensagens do usuário AWS final tenta primeiro a entrega do RCS. Se a entrega do RCS falhar (por exemplo, o dispositivo ou a operadora do destinatário não oferecer suporte ao RCS), o serviço repetirá automaticamente a mensagem via SMS usando um número de telefone do mesmo pool. Você não precisa implementar a lógica de fallback em seu aplicativo.
-
Roteamento inteligente — O serviço seleciona a melhor identidade de origem do pool com base no destino, na disponibilidade do canal e no histórico fixo de envio. Esse roteamento acontece de forma transparente com cada
SendTextMessagechamada. -
Chamada de API única — Você especifica o ID do pool como a identidade de origem em sua
SendTextMessagesolicitação. O serviço determina se deve ser entregue via RCS ou SMS sem nenhuma lógica adicional de sua parte. -
Flexibilidade para mudanças futuras — Você pode adicionar ou remover números de telefone e agentes do AWS RCS de um pool a qualquer momento sem alterar o código do seu aplicativo. Por exemplo, você pode adicionar um número gratuito para enviar SMS ou trocar um número 10DLC sem modificar sua integração de envio.
-
Sem custo ou desvantagem — Criar um pool e adicionar identidades de origem a ele não gera custos adicionais. Mesmo com um único número de telefone ou um único agente do AWS RCS, o uso de um pool oferece a flexibilidade de adicionar mais identidades posteriormente, sem alterações no aplicativo.
nota
Recomendamos sempre usar um pool para enviar mensagens. Não há custo ou desvantagem em usar um pool, mesmo com uma única identidade de origem. Como RCS-to-SMS alternativa, o pool deve conter um agente do AWS RCS e pelo menos um número de telefone SMS. Começar com um pool desde o início significa que você pode adicionar números alternativos de SMS ou agentes adicionais do AWS RCS posteriormente, sem modificar seu código de envio.
Pool-per-use-case modelo
Recomendamos criar um pool por caso de uso. Cada pool deve conter todos os números de telefone e o agente do AWS RCS que servem a uma única finalidade de envio de mensagens. Por exemplo:
-
Um pool transacional para códigos OTP e notificações de conta, contendo seu agente AWS RCS e um número 10DLC registrado para mensagens transacionais.
-
Um pool de marketing para mensagens promocionais, contendo o mesmo agente do AWS RCS (ou um diferente) e um número gratuito registrado para marketing.
-
Um pool de lembretes de compromissos para agendar notificações, contendo seu agente do AWS RCS e um número de telefone dedicado para mensagens relacionadas a compromissos.
Esse modelo garante que, quando a entrega do RCS falhar e o serviço voltar ao SMS, a mensagem alternativa seja enviada de um número de telefone registrado e aprovado para o mesmo caso de uso. Isso mantém suas mensagens em conformidade com os requisitos da operadora e os termos de registro.
Risco de conformidade com o envio em nível de conta
Quando você envia mensagens no nível da conta (sem especificar um pool ou identidade de origem), o AWS End User Messaging seleciona uma identidade de origem de todas as identidades disponíveis em sua conta. Se sua conta tiver vários números de telefone registrados para diferentes casos de uso, o serviço poderá selecionar um número de telefone que não corresponda ao conteúdo da sua mensagem.
Importante
Account-level o envio com casos de uso mistos cria um risco de conformidade. Por exemplo, se sua conta tiver um número 10DLC registrado para mensagens OTP e um número gratuito registrado para lembretes de compromissos, uma mensagem OTP que retorne ao SMS poderá ser enviada do número gratuito de lembretes de compromissos. Isso viola os termos de registro desse número e pode resultar na filtragem da operadora ou na suspensão do número.
Para evitar esse risco, use o envio baseado em pool com um pool por caso de uso. Quando você especifica um ID de pool em sua SendTextMessage solicitação, o serviço seleciona somente identidades de origem desse pool. Como todas as identidades no pool são registradas para o mesmo caso de uso, a mensagem alternativa sempre é enviada de um número apropriado.
| Abordagem de envio | Comportamento alternativo do SMS | Risco de conformidade |
|---|---|---|
| Pool-based (recomendado) | Volta para um número de telefone no mesmo pool, registrado para o mesmo caso de uso | Baixo — o número alternativo corresponde ao caso de uso da mensagem |
| Account-level | Volta para qualquer número de telefone dedicado ou ID de remetente disponível na conta. Não volta às rotas compartilhadas. | Alto — o número alternativo pode não corresponder ao caso de uso da mensagem se vários casos de uso compartilharem a conta |
| Direto (AWS RCS Agent ARN) | Sem recurso de SMS | Nenhuma — a mensagem é entregue somente via RCS ou não é entregue |
Lógica de fallback e ordem de prioridade
Quando o AWS End User Messaging seleciona uma identidade de origem para uma mensagem (de um pool ou de todas as identidades da conta), ele avalia as identidades na seguinte ordem de prioridade:
-
Identidade fixa — Se existir um emparelhamento de envio fixo para o número de telefone de destino e a identidade ainda estiver disponível, o serviço usará essa identidade.
-
Agente AWS RCS — Se não houver emparelhamento fixo, o serviço tentará a entrega do RCS por meio de um agente do AWS RCS disponível.
-
Código curto de SMS — Se o RCS não estiver disponível, o serviço seleciona um código curto de SMS.
-
SMS 10DLC — Se nenhum código curto estiver disponível, o serviço seleciona um número 10DLC.
-
Toll-Free Número SMS — Se nenhum número 10DLC estiver disponível, o serviço selecionará um número gratuito.
-
ID do remetente do SMS — Se nenhuma outra identidade estiver disponível, o serviço seleciona uma ID de remetente.
Essa ordem de prioridade se aplica ao escopo do padrão de envio que você usa. Para envio baseado em pool, o serviço considera apenas identidades no pool especificado. Para envio em nível de conta, o serviço considera todas as identidades em sua conta.
Recurso automático de SMS
Quando você envia uma mensagem por meio de um pool ou no nível da conta, as mensagens do usuário AWS final retornam automaticamente para o SMS se a entrega do RCS não for possível. O fallback é assíncrono:
Se o AWS End User Messaging enviar com êxito a mensagem RCS, mas não receber uma confirmação de entrega ou um sinal de falha em 25 segundos, o serviço retornará ao SMS. Isso trata dos casos em que a infraestrutura do RCS aceita a mensagem, mas a entrega é interrompida (por exemplo, o dispositivo do destinatário está temporariamente inacessível, a operadora não oferece suporte ao RCS ou o dispositivo não está). RCS-capable
nota
O envio direto (especificando um ARN do agente AWS RCS como identidade de origem) não oferece suporte ao fallback automático de SMS. Se você precisar de um substituto de SMS, use o envio baseado em pool.
Envio fixo
O envio fixo é uma otimização de roteamento que melhora a consistência da entrega. Quando o AWS End User Messaging entrega com êxito uma mensagem para um número de telefone de destino usando uma identidade de origem específica, o serviço se lembra desse emparelhamento por 25 horas. As mensagens subsequentes para o mesmo destino dentro da janela de 25 horas são roteadas pela mesma identidade de origem, desde que ela ainda esteja disponível no pool ou na conta.
O envio fixo se aplica tanto à entrega de RCS quanto de SMS. Por exemplo, se uma mensagem for entregue via RCS por meio de seu agente AWS RCS, a próxima mensagem para o mesmo destino dentro de 25 horas também será tentada via RCS por meio do mesmo agente. Se a mensagem anterior foi entregue por SMS (após o fallback do RCS), a próxima mensagem será tentada via SMS por meio do mesmo número de telefone.
O serviço repete periodicamente a entrega do RCS, mesmo quando a identidade fixa é um número de telefone SMS. Isso garante que os destinatários cujos dispositivos obtenham suporte ao RCS (por exemplo, após o lançamento de uma operadora ou a atualização do dispositivo) comecem a receber mensagens RCS sem intervenção manual.
Principais características do envio fixo:
-
TTL de 25 horas — O emparelhamento fixo expira 25 horas após a última entrega bem-sucedida. Após a expiração, o serviço reavalia a ordem de prioridade da identidade de origem para a próxima mensagem.
-
Tentativa automática de RCS — Mesmo quando a identidade fixa é um número de telefone SMS, o serviço tenta periodicamente a entrega do RCS para verificar se o destinatário agora oferece suporte ao RCS.
-
Sem lavagem manual — Você não pode limpar ou redefinir manualmente os emparelhamentos de envio fixo. O emparelhamento expira automaticamente após o TTL de 25 horas.
Recibos de entrega durante o fallback
Quando ocorre um fallback de SMS, o AWS End User Messaging gera um único recibo de entrega para o canal final que entregou a mensagem. Se a mensagem for entregue por SMS após o recuo do RCS, o recibo de entrega indicará o SMS como o canal de entrega. Você pode determinar o canal de entrega inspecionando o originationPhoneNumber campo no evento. Se o valor for um ID de agente RCS, a mensagem foi entregue via RCS. Se o valor for um número de E.164 telefone ou um código curto, a mensagem foi entregue por SMS. Para obter mais informações sobre campos de eventos, consulteExemplo AWS Dados de eventos de SMS de mensagens para o usuário final.
Em circunstâncias normais, o AWS End User Messaging revoga a mensagem RCS antes que a mensagem alternativa do SMS seja entregue. Isso evita que o destinatário receba a mesma mensagem duas vezes. No entanto, em casos raros, tanto a mensagem RCS quanto a mensagem substituta do SMS podem ser entregues. Isso pode acontecer se a mensagem RCS for entregue após o tempo limite de 25 segundos, mas antes que a revogação seja concluída. Nesses raros cenários de entrega dupla, você pode receber recibos de entrega dos dois canais.
Para obter informações sobre como a entrega dupla afeta o faturamento, consulteModelo de cobrança e preços do RCS.
Implicações de cobrança do recuo de SMS
Quando uma mensagem volta do RCS para o SMS, você é cobrado pela entrega do SMS, não pela tentativa fracassada de RCS. As mensagens RCS são cobradas somente quando entregues com sucesso ao dispositivo do destinatário. Se a entrega do RCS falhar e a mensagem voltar para SMS, você paga a taxa de SMS por essa mensagem.
Em raros cenários de entrega dupla (em que a mensagem RCS e a mensagem alternativa SMS são entregues), você pode ser cobrado por ambas as entregas. Para obter detalhes completos de cobrança, consulteModelo de cobrança e preços do RCS.
Testando o fallback de SMS
Você pode testar o comportamento alternativo do SMS para verificar se suas mensagens são entregues via SMS quando a entrega do RCS não é possível. Há duas abordagens para testar o recurso de SMS, dependendo se você tem um número de telefone SMS aprovado.
Teste sem um número de SMS aprovado
Você pode verificar se o AWS End User Messaging aciona corretamente o mecanismo de fallback sem um número de telefone SMS aprovado. Mesmo sem um número aprovado, você pode ver os eventos de nova tentativa e falha via SMS, o que confirma que o fallback está funcionando.
Para testar o fallback de SMS sem um número de SMS aprovado
-
Coloque seu dispositivo de teste off-line desativando os dados móveis e/ou ativando o modo avião. Wi-Fi
-
Envie uma mensagem RCS para o dispositivo de teste usando a
SendTextMessageAPI com seu AWS RCS Agent ARN como identidade de origem. -
Verifique o evento da mensagem CloudWatch ou o destino do seu evento. Você deve ver um evento de falha na entrega indicando que a entrega do RCS não foi possível e que o serviço tentou substituir o SMS.
Como não há nenhum número de telefone SMS disponível para reserva, a entrega do SMS também falha. No entanto, o evento confirma que o AWS End User Messaging acionou corretamente o mecanismo de fallback.
Testando com um número de SMS aprovado
Para um teste completo de fallback de SMS de ponta a ponta, adicione um número de telefone SMS aprovado e seu agente do AWS RCS ao mesmo pool telefônico. Isso permite verificar se as mensagens são entregues via SMS quando o RCS não está disponível.
Para testar o fallback de SMS com um número de SMS aprovado
-
Crie um pool telefônico que contenha seu agente do AWS RCS e um número de telefone SMS aprovado (como um número de 10DLC, gratuito ou de código curto).
-
Coloque seu dispositivo de teste off-line desativando os dados móveis e/ou ativando o modo avião. Wi-Fi
-
Envie uma mensagem usando a
SendTextMessageAPI com o ID do pool como identidade de origem. -
Verifique se a mensagem foi entregue por SMS ao seu dispositivo de teste.
-
Verifique o evento de entrega para confirmar se a mensagem foi entregue pelo canal SMS após o fallback do RCS.
Gerenciamento de agentes do AWS RCS em pools
Para obter instruções detalhadas sobre como criar pools com agentes do AWS RCS, adicionar agentes aos pools existentes, entender os requisitos de configuração do pool e remover agentes dos pools, consulte. Gerenciamento de agentes do AWS RCS em pools
