

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á.

# Fallback de RCS para SMS usando pools telefônicos
<a name="rcs-sms-fallback"></a>

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 possibilita o retorno do SMS, a lógica alternativa, o pedido prioritário e as implicações do faturamento. Também aborda as pool-per-use-case melhores práticas e como adicionar e remover agentes do AWS RCS dos pools. Para obter informações gerais sobre pools telefônicos, consulte[Pools telefônicos em SMS de mensagens para usuários AWS finais](phone-pool.md). Para obter informações sobre o gerenciamento de agentes do AWS RCS, consulte[Gerenciando agentes RCS](rcs-agents.md).

**Topics**
+ [Como a entrega do RCS pode falhar](#rcs-sms-fallback-how-rcs-fails)
+ [O que torna possível o fallback de SMS](#rcs-sms-fallback-what-makes-possible)
+ [Por que usar piscinas](#rcs-sms-fallback-why-pools)
+ [Pool-per-use-case modelo](#rcs-sms-fallback-pool-per-use-case)
+ [Risco de conformidade com envio em nível de conta](#rcs-sms-fallback-compliance-risk)
+ [Lógica alternativa e ordem de prioridade](#rcs-sms-fallback-logic)
+ [Implicações de cobrança do fallback de SMS](#rcs-sms-fallback-billing)
+ [Testando o fallback de SMS](#rcs-sms-fallback-testing)
+ [Gerenciamento de agentes do AWS RCS em pools](#rcs-sms-fallback-pool-management)

## Como a entrega do RCS pode falhar
<a name="rcs-sms-fallback-how-rcs-fails"></a>

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 suporta RCS** — A operadora de celular 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 à versão 18).
+ **Agente não ativo na operadora** — Seu agente do AWS RCS ainda não foi aprovado pela operadora do destinatário ou o agente tem status PARCIAL para esse 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 para a entrega de SMS usando um número de telefone do mesmo pool ou conta.

## O que torna possível o fallback de SMS
<a name="rcs-sms-fallback-what-makes-possible"></a>

O SMS fallback exige um agente do AWS RCS e pelo menos um número de telefone SMS 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 do mesmo pool. Um pool com apenas um AWS RCS Agent (e sem números de telefone) não oferece suporte ao recurso de SMS. Se o RCS falhar, a mensagem não será entregue.

**Importante**  
Para que o SMS fallback funcione, seu pool deve conter um AWS RCS Agent e um ou mais números de telefone SMS. Um pool com apenas um único tipo de identidade não oferece alternativa entre canais.

## Por que usar piscinas
<a name="rcs-sms-fallback-why-pools"></a>

Recomendamos o uso de um pool telefônico para todos os casos de uso de mensagens, não apenas para o RCS. As piscinas oferecem as seguintes vantagens:
+ **Recuo automático de SMS** — Quando um pool contém um agente do AWS RCS e números de telefone SMS, o sistema de mensagens de 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 de envio fixo. Esse roteamento acontece de forma transparente com cada `SendTextMessage` chamada.
+ **Chamada única de API** — você especifica o ID do pool como a identidade de origem em sua `SendTextMessage` solicitação. O serviço determina se você deve entregar via RCS ou SMS sem nenhuma lógica adicional do seu lado.
+ **Flexibilidade para futuras mudanças** — 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 aplicativo. Por exemplo, você pode adicionar um número gratuito para SMS de fallback ou trocar um número 10DLC sem modificar sua integração de envio.
+ **Sem custo ou desvantagem** — Criar um pool e adicionar identidades de originação a ele não incorre em 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. Para o RCS-to-SMS fallback, o pool deve conter um AWS RCS Agent 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
<a name="rcs-sms-fallback-pool-per-use-case"></a>

Recomendamos criar um pool por caso de uso. Cada pool deve conter todos os números de telefone e o AWS RCS Agent 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 AWS RCS Agent 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 AWS RCS Agent 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 para o 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 envio em nível de conta
<a name="rcs-sms-fallback-compliance-risk"></a>

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**  
O envio em nível de conta 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 retorna para SMS pode 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 uma 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.


**Comparação de conformidade da abordagem de envio**  

| Abordagem de envio | Comportamento de fallback de SMS | Risco de conformidade | 
| --- | --- | --- | 
| Baseado em piscina (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 | 
| Nível da conta | Volta para qualquer número de telefone disponível na conta | 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 (ARN do agente AWS RCS) | Sem retorno de SMS | Nenhuma — a mensagem é entregue somente via RCS ou não é entregue | 

## Lógica alternativa e ordem de prioridade
<a name="rcs-sms-fallback-logic"></a>

Quando o AWS End User Messaging seleciona uma identidade de origem para uma mensagem (seja de um pool ou de todas as identidades da conta), ele avalia as identidades na seguinte ordem de prioridade:

1. **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.

1. **AWS RCS Agent** — Se não existir um emparelhamento fixo, o serviço tentará a entrega do RCS por meio de um AWS RCS Agent disponível.

1. **Código curto de SMS** — Se o RCS não estiver disponível, o serviço selecionará um código curto de SMS.

1. **SMS 10DLC** — Se nenhum código curto estiver disponível, o serviço seleciona um número 10DLC.

1. **Número gratuito de SMS — Se nenhum número** 10DLC estiver disponível, o serviço seleciona um número gratuito.

1. **ID do remetente do SMS** — Se nenhuma outra identidade estiver disponível, o serviço seleciona uma ID do 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 somente identidades no pool especificado. Para envio em nível de conta, o serviço considera todas as identidades em sua conta.

### Recuo automático de SMS
<a name="rcs-sms-fallback-automatic"></a>

Quando você envia uma mensagem por meio de um pool ou no nível da conta, o AWS End User Messaging volta automaticamente para SMS se a entrega do RCS não for possível. O fallback é assíncrono:

Se o AWS End User Messaging enviar com sucesso 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 lida com 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 é compatível com o RCS).

**nota**  
O envio direto (especificando um ARN do AWS RCS Agent 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
<a name="rcs-sms-fallback-sticky"></a>

O envio fixo é uma otimização de roteamento que melhora a consistência da entrega. Quando o AWS End User Messaging entrega com sucesso 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 ainda estejam disponíveis 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 AWS RCS Agent, a próxima mensagem para o mesmo destino em 25 horas também será tentada via RCS por meio do mesmo agente. Se a mensagem anterior foi entregue via SMS (após o retorno 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 para RCS (por exemplo, após a implantação de uma operadora ou atualização do dispositivo) comecem a receber mensagens RCS sem intervenção manual.

Principais características do envio contínuo:
+ **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.
+ Nova **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 período de espera
<a name="rcs-sms-fallback-delivery-receipts"></a>

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 via SMS após o retorno do RCS, o recibo de entrega indicará SMS como o canal de entrega.

Em circunstâncias normais, o AWS End User Messaging revoga a mensagem RCS antes que a mensagem SMS de fallback seja entregue. Isso impede que o destinatário receba a mesma mensagem duas vezes. No entanto, em casos raros, tanto a mensagem RCS quanto a mensagem SMS de fallback 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 para ambos os canais.

Para obter informações sobre como a entrega dupla afeta o faturamento, consulte[Modelo de cobrança e preços do RCS](rcs-billing.md).

## Implicações de cobrança do fallback de SMS
<a name="rcs-sms-fallback-billing"></a>

Quando uma mensagem volta do RCS para o SMS, você é cobrado pela entrega do SMS, não pela tentativa malsucedida de RCS. As mensagens RCS são cobradas somente quando entregues com sucesso no dispositivo do destinatário. Se a entrega do RCS falhar e a mensagem voltar para SMS, você pagará a taxa de SMS dessa mensagem.

Em cenários raros de entrega dupla (em que tanto a mensagem RCS quanto a mensagem SMS de fallback são entregues), você pode ser cobrado por ambas as entregas. Para obter detalhes completos sobre o faturamento, consulte[Modelo de cobrança e preços do RCS](rcs-billing.md).

## Testando o fallback de SMS
<a name="rcs-sms-fallback-testing"></a>

Você pode testar o comportamento de fallback 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.

### Testando sem um número de SMS aprovado
<a name="rcs-sms-fallback-testing-without-sms"></a>

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 repetição 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**

1. Coloque seu dispositivo de teste off-line desativando os dados móveis e o Wi-Fi ou ativando o modo avião.

1. Envie uma mensagem RCS para o dispositivo de teste usando a `SendTextMessage` API com seu ARN do AWS RCS Agent como identidade de origem.

1. Verifique a mensagem do evento em CloudWatch ou o destino do 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 o retorno do SMS.

Como não há um número de telefone SMS disponível para fallback, 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
<a name="rcs-sms-fallback-testing-with-sms"></a>

Para um teste completo de fallback de end-to-end SMS, adicione um número de telefone SMS aprovado e seu AWS RCS Agent ao mesmo pool telefônico. Isso permite que você verifique 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**

1. Crie um pool telefônico que contenha seu AWS RCS Agent e um número de telefone SMS aprovado (como um número de telefone de 10 DLC, ligação gratuita ou código curto).

1. Coloque seu dispositivo de teste off-line desativando os dados móveis e o Wi-Fi ou ativando o modo avião.

1. Envie uma mensagem usando a `SendTextMessage` API com o ID do pool como identidade de origem.

1. Verifique se a mensagem foi entregue via SMS para seu dispositivo de teste.

1. 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
<a name="rcs-sms-fallback-pool-management"></a>

Para step-by-step obter instruções 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](phone-pool-rcs-agents.md).