Portabilidade numérica: o que ISPs e operadoras precisam saber

A portabilidade numérica é o mecanismo regulatório que permite ao assinante manter o número de telefone ao trocar de provedor, de tipo de transporte ou de categoria de serviço. Para provedores de serviços de internet (ISPs) e operadoras, é também um dos processos administrativos mais trabalhosos da operação de voz e um dos pontos em que mais se perde cliente quando algo dá errado. A maioria das operadoras só se dá conta disso na primeira portabilidade rejeitada.

Este artigo é a referência operacional para ISPs, ILECs, CLECs, provedores de serviços gerenciados (MSPs) e operadoras de atacado que lidam com port-in e port-out (a entrada e a saída de números) como parte permanente da rotina da operação de voz, e não só como um evento pontual de migração. Explicamos o que é, na prática, a portabilidade numérica local (Local Number Portability, LNP), como funcionam os principais regimes na América do Norte, no Reino Unido, na União Europeia e em vários mercados da APAC, o que o Controlador de Borda de Sessão (SBC) precisa fazer na camada de roteamento depois que um número é portado, como é o fluxo operacional de port-in e port-out e quais falhas estão por trás da maioria das disputas de portabilidade.

Se você está fazendo uma migração pontual da PSTN para uma plataforma VoIP, o ponto de partida certo é o guia de migração para ISPs que estão substituindo a PSTN. Este artigo é para a equipe que lida com portabilidades no dia a dia, depois que a migração já terminou. Para entender a arquitetura SIP em que tudo isso se encaixa, veja a página pilar de SIP trunking (troncos de voz sobre IP) e interoperabilidade.

O que é, de fato, a portabilidade numérica

A portabilidade numérica é uma promessa regulatória: quando o assinante troca de provedor de voz, o número vai junto. A regra nasceu para estimular a concorrência e hoje faz parte da política de telecomunicações de todos os mercados relevantes. Nos Estados Unidos, a exigência vem da Seção 251 do Telecommunications Act de 1996 (veja a visão geral da FCC sobre a Wireless Local Number Portability). No Reino Unido, a base são as General Conditions of Entitlement da Ofcom, e na União Europeia a regra está no artigo 106 do Código Europeu das Comunicações Eletrônicas (EECC). Austrália, Brasil, Índia e a maioria dos mercados da APAC têm regras equivalentes, administradas pelos respectivos reguladores.

Na prática, existem três tipos de portabilidade. A portabilidade de provedor é o caso mais comum: o número continua o mesmo e o provedor muda. A portabilidade geográfica permite que o número acompanhe o assinante para outro endereço físico, algo que o NANP só aceita dentro do mesmo centro de tarifação, mas que vários mercados da UE autorizam de forma mais ampla. A portabilidade de serviço leva o número de um tipo de serviço para outro, por exemplo de fixo para móvel, e continua rara fora de poucas jurisdições. Para ISPs e operadoras, é a portabilidade de provedor que consome tempo de operação.

A portabilidade vale para o número em si. O plano de serviço, a caixa postal, os recursos de chamada e as credenciais SIP ficam para trás. O assinante que porta um número da operadora doadora para a operadora receptora está contratando um serviço novo que, por acaso, usa o mesmo identificador do anterior. Essa distinção gera uma quantidade surpreendente de confusão entre os assinantes e de chamados de suporte depois da portabilidade, e é um dos motivos pelos quais a portabilidade numérica é tratada mais como disciplina operacional do que como tarefa técnica.

Como a LNP funciona no plano de numeração norte-americano (NANP)

O NANP abrange os Estados Unidos, o Canadá e a maior parte dos territórios do Caribe. A base de dados central que viabiliza a LNP em toda essa área é o NPAC, operado pela iconectiv sob um contrato plurianual concedido pelo NAPM (o comitê do NANC que seleciona o LNPA). Todo número elegível para portabilidade no NANP tem um registro no NPAC que associa o número de telefone a um LRN, e esse LRN identifica a central que atende o número naquele momento. É para o LRN que a rede encaminha as chamadas depois que a portabilidade é executada.

Quem participa

A operadora doadora atende o número hoje e é obrigada pelas regras da FCC e da CRTC a colaborar com a portabilidade. A operadora receptora assume o número e é responsável por iniciar o LSR, coletar a LOA, validar o CSR, coordenar a virada e avisar o assinante. O NPAC mantém o mapeamento oficial LRN-to-TN. A iconectiv administra o NPAC, o LERG, o registro de Service Provider Identifiers (SPID) e o programa de tokens Service Provider Code (SPC), que vincula os registros de autorização de números à atestação STIR/SHAKEN.

O passo a passo

Um port-in começa quando o assinante entrega a LOA assinada à operadora receptora. Ela confere o LSR com o CSR obtido da operadora doadora e envia o pedido por uma clearinghouse (NeuStar, iconectiv, TNS ou Bandwidth, conforme a configuração de cada operadora), a intermediária que encaminha as solicitações entre as partes. A operadora doadora analisa o LSR, confirma a titularidade da conta e devolve um FOC com o horário de virada acordado, normalmente expresso como uma data e uma janela de quatro horas. Na virada, o registro do número portado no NPAC é atualizado para apontar para o LRN da operadora receptora. A partir daí, toda operadora do NANP que faz a consulta de LNP (o chamado dip) para esse número encaminha a chamada para a operadora receptora.

Portabilidade de atacado e portabilidade de assinante

Para ISPs e operadoras, as duas modalidades importam. A portabilidade de assinante envolve um único cliente final que troca de provedor e segue o processo padrão de LSR. Já a portabilidade de atacado abrange um bloco de números que passa de uma operadora upstream para outra, muitas vezes por causa de uma aquisição ou da troca de fornecedor de atacado, e é administrada em lote pelos mesmos mecanismos do NPAC. Um ISP pequeno que entrega o serviço por meio de um parceiro de atacado pode enfrentar as duas ao mesmo tempo: a operadora upstream dele muda (uma portabilidade de atacado que o ISP não pediu) e, simultaneamente, um assinante decide sair (um port-out de assinante, este sim solicitado pelo ISP). Coordenar as duas situações é delicado na operação e é uma das falhas que abordamos mais adiante neste artigo.

Como a LNP funciona fora da América do Norte

Todo mercado de voz regulamentado tem alguma forma de portabilidade numérica, mas o modelo administrativo e o ritmo operacional variam. Três padrões predominam.

Reino Unido (Ofcom)

Historicamente, o Reino Unido adotava um modelo conduzido pela operadora doadora, em que ela controlava a portabilidade e as chamadas sempre passavam primeiro pela doadora antes de seguir para o destino. A Ofcom está implantando aos poucos um modelo conduzido pela operadora receptora, semelhante à arquitetura do NANP, com uma base de dados central de referência e roteamento direto para a receptora. Nesse modelo, a portabilidade leva um dia útil para assinantes residenciais, e clientes empresariais podem ter a execução no mesmo dia em alguns cenários. O Reino Unido usa mensagens de portabilidade baseadas em XML, trocadas pela Openreach e pelos sistemas das principais operadoras.

União Europeia (EECC)

Pelo artigo 106 do EECC, todos os Estados-membros devem implementar a portabilidade entre provedores em até um dia útil, sem custo para o assinante. Cada Estado-membro administra sua própria base central (a OPTA na Holanda, o registro do BIPT na Bélgica, o sistema da BNetzA na Alemanha, entre outros), mas os conceitos operacionais são os mesmos: a operadora receptora inicia, a doadora valida, um registro central guarda a alteração e o roteamento é atualizado. Muitos mercados da UE usam ENUM (mapeamento de E.164 para URI) como mecanismo de consulta de roteamento para números portados, o que torna o trabalho do SBC na camada de roteamento um pouco diferente de um dip de LRN no NANP.

Austrália, Brasil, Índia e outros mercados da APAC

Austrália (ACMA, modelo conduzido pela receptora, prazos curtos), Brasil (ANATEL, base central de portabilidade) e Índia (TRAI, com Mobile Number Portability Operators regionais) mantêm, cada um, seus próprios registros centrais e fluxos de portabilidade. O que todos têm em comum é uma base de dados central e uma troca definida entre a operadora doadora e a receptora. Em relação ao NANP, o comportamento do SBC muda no tipo de consulta: um dip de LRN no NPAC, no caso do NANP; uma consulta ENUM em boa parte da UE; uma consulta à base central de portabilidade no Brasil; e assim por diante. Tecnicamente, cada tipo de consulta é uma requisição de API diferente, feita a uma fonte de verdade diferente, mas a pergunta de roteamento por trás é sempre a mesma: quem atende este número agora?

Portabilidade entre países

A portabilidade numérica é nacional por definição. Um número dos EUA não pode ser portado para uma operadora do Reino Unido, nem o contrário. Operadoras presentes em vários países mantêm um fluxo de LNP separado para cada jurisdição. O tráfego internacional de voz que sai de um número portado segue pelos mesmos caminhos de saída de qualquer outra chamada; a mudança de portabilidade só tem efeito no mercado de origem.

A mecânica do roteamento: onde entra o SBC

Antes da portabilidade numérica, cada número de telefone tinha um endereço fixo: o NPA-NXX dos dígitos discados dizia à rede exatamente qual central o atendia. O roteamento era estático e ficava no LERG. A portabilidade derrubou essa premissa. Depois que o número é portado, o NPA-NXX ainda indica o centro de tarifação original, mas a central que de fato atende o número está em outro lugar. A rede precisa descobrir a nova localização a cada chamada, e é aí que entra o SBC.

O dip de LNP

O dip de LNP é uma consulta à base de portabilidade para obter o identificador de roteamento atual de um número. No NANP, o dip retorna o LRN. Nos mercados da UE que usam ENUM, ele retorna a URI para onde a chamada deve ser roteada. Em todos os casos, o SBC extrai o número chamado do INVITE de entrada, consulta a base apropriada (ou uma cópia em cache) e reescreve a decisão de roteamento com base no resultado.

O dip pode ser feito diretamente na base nacional, em um espelho local atualizado periodicamente ou em um fornecedor que revende acesso ao dip (TransNexus, Neustar, iconectiv, Bandwidth, TNS). Para ISPs e operadoras menores, o mais comum é contratar o dip como serviço de terceiros. O custo por dip varia conforme o fornecedor e o volume, normalmente uma fração de centavo, mas na escala de uma operadora esses custos se somam, e por isso manter os resultados em cache com TTLs bem calibrados faz diferença na operação.

Tratamento da flag NPDI

A flag NPDI na sinalização SIP indica que um nó anterior já fez o dip de LNP para esta chamada. Quando o SBC vê NPDI=yes em um INVITE de entrada, o comportamento correto é respeitar o resultado recebido e pular o dip. Refazer o dip de um número que já foi resolvido antes desperdiça tempo, custa dinheiro e pode gerar inconsistências de roteamento se a base consultada antes e a consultada depois divergirem. Um SBC bem configurado sempre verifica o NPDI antes de iniciar um dip e sempre marca o NPDI nos INVITEs de saída depois de fazer o próprio dip, para que os nós seguintes possam fazer o mesmo.

Onde o dip entra no fluxo de roteamento

O dip de LNP normalmente acontece no início do estabelecimento da chamada, depois da validação SIP básica e antes da decisão de roteamento. O resultado confirma a rota original baseada no NPA-NXX (o número não foi portado ou voltou para a central original) ou reescreve a rota para a nova operadora que atende o número. O ProSBC implementa dips de LNP por meio dos seus módulos de API: o script de roteamento dispara uma consulta HTTP ou SIP ao provedor de LNP, interpreta a resposta e atualiza a decisão de roteamento antes que a chamada avance. Para ver em detalhe como consultas externas se encaixam no processamento de chamadas do SBC, confira o guia de integração de roteamento de chamadas via API REST do SBC.

Por que o SBC é o lugar certo para isso

São dois motivos. Primeiro, o SBC é o ponto natural de entrada: ele já termina o SIP, ancora a mídia, aplica as regras de manipulação de cabeçalhos SIP e é o primeiro salto em que a lógica de roteamento de chamadas entra em ação. Fazer o dip de LNP nessa camada mantém as decisões de roteamento em um só lugar. Segundo, a arquitetura B2BUA dá ao SBC controle total sobre o INVITE de saída, o que inclui inserir o NPDI, reescrever a Request-URI, definir o LRN como número de roteamento e repassar intacto o número chamado original para o faturamento mais adiante.

O fluxo operacional: port-in e port-out

A camada técnica é a metade mais fácil. É no fluxo administrativo que a maioria das portabilidades dá certo ou falha, e é também ali que os ISPs sem equipe dedicada de operações de voz sentem o peso. O fluxo tem dois lados espelhados.

Port-in (você é a operadora receptora)

Receba a LOA assinada pelo cliente. Valide o pedido com o CSR obtido da operadora doadora; nome de faturamento ou endereço de serviço divergentes são o motivo mais comum de rejeição do LSR. Envie o LSR pela sua clearinghouse com a data de virada desejada. Acompanhe o retorno do FOC e resolva os códigos de rejeição que a operadora doadora apresentar (erro de digitação no número da conta, endereço divergente, conta congelada, saldo pendente). Com o FOC em mãos, provisione o roteamento no seu SBC, confirme a cobertura do plano de discagem, configure o correio de voz e os recursos que o assinante espera ter e informe a ele o horário da virada. Na virada, verifique se as chamadas de entrada chegam à nova plataforma e se o identificador de chamadas (caller ID) aparece corretamente nas chamadas de saída.

Port-out (você é a operadora doadora)

Receba o LSR da operadora receptora. Valide-o com o seu CSR e responda dentro do SLA definido pelo regulador: as regras da FCC exigem que portabilidades simples sejam concluídas em um dia útil, e as portabilidades empresariais complexas levam mais tempo. Emita o FOC com o horário de virada acordado ou rejeite o LSR com um código específico se a documentação não bater. Coordene internamente para que o faturamento encerre a linha na virada, para que os registros de detalhe de chamada (CDRs) fiquem guardados pelo prazo regulatório exigido e para que o número saia de forma limpa das tabelas de roteamento do seu SBC.

Quem cuida de cada etapa

Em uma operadora com equipe completa, o fluxo é dividido: a área de operações de voz fica com a troca de LSR e FOC, o faturamento encerra a conta, a equipe do SBC faz a mudança de roteamento e o time de sucesso do cliente conversa com o assinante. Em um ISP menor, a mesma pessoa costuma tocar três ou quatro dessas etapas, e é aí que os erros aparecem. Duas práticas diferenciam as operadoras que mantêm um fluxo de portabilidade limpo. A primeira é tratar cada portabilidade como um fluxo coordenado, com passagens de bastão explícitas e um único responsável: um ticket de acompanhamento, um checklist e uma validação em cada etapa. A segunda é automatizar a mudança de roteamento para que, na hora da virada, a atualização no SBC aconteça por uma requisição de API, em vez de depender de quem estiver de plantão aplicando a configuração manualmente às 2 da manhã.

Falhas mais comuns

A maioria das falhas de portabilidade tem origem administrativa. Em milhares de disputas de portabilidade, o padrão se repete: cerca de quatro em cada cinco vêm de dados divergentes, prazos perdidos ou falta de clareza sobre quem é o responsável, e a camada técnica de roteamento responde pelo restante. As falhas abaixo são as que as operadoras mais encontram.

Divergência no CSR e rejeição do FOC

O nome de faturamento do assinante no LSR precisa bater exatamente com o CSR da operadora doadora. “John A. Smith” e “John Smith” podem ser tratados como identidades diferentes. O mesmo vale para endereços, números de conta e contatos autorizados. Um único caractere divergente basta para rejeitar o LSR, o que custa à operadora receptora um novo ciclo de coleta da LOA e de reenvio. A solução está no processo: a operadora receptora obtém o CSR antes de enviar o LSR, compara linha a linha com a LOA e resolve qualquer divergência com o assinante antes que algo chegue à operadora doadora.

Janela de virada perdida

O FOC define um horário de virada específico. Se a operadora receptora não tiver o roteamento provisionado no SBC nesse momento, as chamadas de entrada para o número portado falham até que o roteamento esteja configurado. O assinante aceita passar por uma portabilidade; o que ele não aceita são horas sem receber chamadas. A solução é provisionar o roteamento no SBC com antecedência e vincular a ativação ao horário do FOC pela API do SBC, para que a mudança de roteamento seja acionada por evento, sem depender de alguém na frente do teclado.

Snapback (reversão da portabilidade)

A operadora doadora pode reverter uma portabilidade dentro de um prazo definido, normalmente 30 dias no NANP, em casos de port-out fraudulento ou em resposta a uma contestação do assinante. A operadora receptora fica com um registro órfão: o número voltou para a doadora, mas as tabelas de roteamento locais, os arquivos de CDR e a base de faturamento ainda apontam para a receptora. Lidar com snapback é uma questão de processo: uma conciliação periódica entre as tabelas de roteamento do SBC e o mapeamento oficial do NPAC detecta os registros órfãos antes que eles causem falhas de roteamento.

Falhas no dip de LRN

Se o SBC não consegue fazer o dip de LNP (timeout do provedor, erro de rede, credenciais de API vencidas, cache miss sem fallback), o roteamento volta para a lógica baseada em NPA-NXX e a chamada é entregue ao centro de tarifação original. Para números portados, esse é o destino errado. A solução é ter redundância no dip: configure provedores de LNP primário e secundário no SBC, use um timeout curto (normalmente de 500 a 2.500 ms), registre cada falha de dip nos CDRs para monitoramento e estabeleça uma política de fallback clara para quando os dois provedores falharem. Deixar as chamadas caírem no roteamento por NPA-NXX é aceitável em algumas configurações de operadora e inaceitável em outras; a política precisa ser definida de forma explícita.

Disputas inter-LATA e intra-LATA

ILECs menores às vezes resistem a portabilidades intra-LATA, alegando motivos tarifários ou regulatórios que, em geral, são mais procedimentais do que substantivos. O caminho para resolver é a escalada administrativa pela clearinghouse e, em alguns casos, pela FCC. A medida preventiva mais eficaz é manter a documentação do LSR precisa e completa, o que elimina os argumentos procedimentais para a resistência.

Perda de correio de voz e de recursos

Mensagens de correio de voz, recursos de chamada e personalizações por número são específicos de cada plataforma e não acompanham o número na portabilidade. O assinante espera, com razão, encontrar depois da portabilidade tudo o que tinha antes, e liga para o suporte quando isso não acontece. Alinhar as expectativas na etapa de coleta da LOA é a única solução duradoura, junto com um checklist de recursos na virada para garantir que a nova plataforma seja provisionada com os mesmos recursos de chamada que o assinante tinha na antiga.

Portabilidade por DID e portabilidade por tronco

Quando o assinante tem um tronco com muitos DIDs, cada DID é portado individualmente, com seu próprio LSR. Tentar portar um tronco de mil DIDs como um único registro pode resultar em portabilidades parciais, em que alguns DIDs vão para a operadora receptora e outros ficam na doadora, quebrando o roteamento de entrada de metade do tronco. A portabilidade de atacado usa mecanismos de portabilidade em bloco justamente para evitar isso; já a portabilidade de grandes inventários de DIDs no nível do assinante exige lotes coordenados.

STIR/SHAKEN e a documentação da portabilidade

No NANP, a documentação de portabilidade deixou de ser uma questão puramente operacional. No modelo da FCC para autenticação do chamador, a atestação de nível A exige que o provedor de serviços de origem tenha uma relação direta e verificada com quem faz a chamada, além de registros precisos de qual número está atribuído a qual cliente. A LOA, o CSR e o FOC são a prova de que o provedor pode atestar legitimamente no nível A as chamadas originadas no número portado. Provedores que não conseguem apresentar uma documentação de portabilidade limpa estão sendo rebaixados cada vez mais para a atestação B ou C pelos parceiros upstream que fazem a assinatura, com impacto mensurável na taxa de completamento de chamadas.

Na prática, o fluxo de portabilidade agora alimenta diretamente o fluxo de compliance. Guarde as LOAs em arquivo de longo prazo, vincule cada uma ao registro de portabilidade no NPAC e armazene tudo de forma que a equipe de compliance consiga recuperar os documentos quando precisar. Para um passo a passo mais completo dos requisitos de atestação e do caminho operacional da assinatura de nível C até a de nível A, veja o guia de atestação STIR/SHAKEN de nível A.

O que avaliar em um SBC para operações de LNP

Um SBC que opera em um ambiente com portabilidade ativa tem requisitos específicos. A maioria decorre dos pontos de arquitetura já abordados.

Um motor de roteamento programável faz diferença porque cada regime de LNP é diferente. O NANP usa o NPAC e dips de LRN; a UE usa ENUM em muitos mercados; Brasil e Índia usam bases centrais de portabilidade com semânticas de consulta próprias. Com uma camada de roteamento programável, o SBC implementa cada tipo de consulta sem esperar o ciclo de lançamentos do fabricante. O motor de roteamento Ruby do ProSBC expõe mais de 100 parâmetros de chamada e aceita consultas HTTP, Radius e SIP a qualquer sistema externo, o que facilita adicionar um novo provedor de LNP ou um novo formato de consulta.

O reconhecimento do NPDI na entrada e na saída significa que o SBC deve detectar o NPDI nas chamadas de entrada e respeitar o resultado do dip anterior, além de marcar o NPDI nas chamadas de saída depois de fazer o próprio dip. Sem isso, um dip feito em um único salto vira uma cascata de dips ao longo de vários saltos.

O controle do comportamento de LNP por NAP atende às necessidades diferentes de cada grupo de troncos. Um NAP voltado a uma operadora de atacado pode sempre confiar no NPDI recebido; um NAP voltado a assinantes pode sempre fazer o dip localmente; um tronco de Teams Direct Routing pode precisar de outra política. O SBC deve permitir que o operador defina o comportamento de LNP por NAP, sem mexer na política global.

A redundância no dip e o registro de falhas se traduzem em provedores primário e secundário, timeouts curtos, registro do resultado de cada dip nos CDRs e um comportamento de fallback explícito. Como o dip de LNP não é opcional, o modo de falha precisa ser definido com antecedência e poder ser observado depois.

As mudanças de roteamento via API tiram a hora da virada das mãos de uma pessoa: o SBC deve aceitar atualizações de roteamento pela API REST para que o fluxo de portabilidade dispare a mudança exatamente no horário que o FOC determina.

O detalhamento dos CDRs para auditorias de portabilidade precisa cobrir cada resultado de dip, cada LRN, cada flag NPDI e cada reescrita de Request-URI, para que a equipe de operações consiga reconstruir o roteamento de qualquer chamada contestada.

Perguntas frequentes