Resumo

  • A RFC 3057 separou o encerramento físico do canal D ISDN do local onde o Q.931 processava as chamadas: o gateway de sinalização encerrava o Q.921 e o IUA enviava as primitivas dessa fronteira, por SCTP, até um servidor de aplicações.
  • O failover entre processos ASP podia redirecionar a sinalização, mas recuperar o transporte não recuperava o estado da chamada. A RFC 4233, sucessora da RFC 3057, diz que chamadas em transição podem falhar se os processos de aplicação não compartilharem o estado por um mecanismo fora do IUA.

A camada superior mudou de lugar; o fio, não

Em uma arquitetura ISDN tradicional, o canal D leva a sinalização usada pelos terminais para estabelecer e administrar chamadas comutadas por circuito. O Q.921 fornece o serviço de enlace de dados; Q.931 e QSIG usam esse serviço. Publicada em fevereiro de 2001, a RFC 3057 aproveitou essa fronteira de protocolo para separar onde cada função era executada.

O Signaling Gateway (SG) recebia a sinalização por uma interface ISDN padrão e encerrava o Q.921. No lado IP, um Media Gateway Controller (MGC) hospedava a camada Q.931 correspondente e o processamento de chamadas. Entre eles, a camada ISDN Q.921-User Adaptation — IUA — transportava as primitivas da fronteira usando SCTP. Isso não transformava o circuito do assinante, o canal D ou cada chamada em um objeto IP: a interface física e o comportamento local do Q.921 continuavam no gateway.

A distinção era operacional. A primitiva DL-DATA transporta uma mensagem Q.931; estabelecimento, liberação e dados sem confirmação representam resultados diferentes do enlace. Por isso, o IUA precisava preservar a identidade da interface e o significado de cada primitiva. O controlador remoto podia processar mensagens de chamada sem fingir que havia assumido o próprio canal D.

Um identificador de interface, um mapeamento local

O Interface Identifier associava uma mensagem à interface física correspondente no SG. Podia ser um inteiro ou texto, mas sua semântica era local: gateway e servidor de aplicações coordenavam o valor. A RFC não o tornava significativo entre gateways diferentes. O que parecia um nome global era, na prática, uma chave local que conectava contextos de sinalização.

O SG associava esse identificador a um Application Server e a um Application Server Process (ASP) ativo. O servidor podia ser um serviço lógico formado por uma lista ordenada de ASPs, como um controlador principal e outro de reserva. O gateway precisava saber qual processo recebia o tráfego de cada interface; esse vínculo podia mudar durante o failover.

A RFC 3057 recomendou SCTP e um fluxo SCTP separado para cada canal D, reduzindo espera e atraso de buffer entre canais independentes. O fluxo era parte do transporte; o Interface Identifier continuava indicando a interface física a que a mensagem pertencia. Estado da associação, sequência do fluxo, mapeamento local e estado ativo do ASP se relacionavam, mas nenhum substituía os demais.

Failover não copia o histórico da chamada

O projeto permitia escolher o nível de redundância. Uma configuração 1+0 não tinha ASP redundante. No modo 1+1 ativo/em espera, um processo tratava o tráfego e outro podia assumir. O modelo mais geral n+k descrevia n processos necessários para a carga e k processos de reserva para substituir os que falhassem. Mensagens IUA permitiam que SG e ASP trocassem estado e determinassem o destino da sinalização.

Mas uma associação ativa com o processo de reserva não prova que ele conheça o estado de uma chamada já em andamento. A RFC 4233, que substituiu a RFC 3057 em 2006, explicita essa diferença. Em redes de nível operadora, a falha de um ASP NÃO DEVERIA derrubar chamadas estáveis; cumprir esse objetivo pode exigir que os ASPs compartilhem o estado das chamadas. Já chamadas em transição PODEM falhar. Memória compartilhada ou um protocolo ASP-a-ASP podem reduzir esse risco, mas esse protocolo fica fora do escopo do IUA.

Não era uma deficiência oculta do SCTP. O SCTP pode informar o estado de uma associação, sequenciar mensagens dentro de cada fluxo e oferecer multihoming. São propriedades de transporte. Elas não dizem ao controlador reserva quais decisões já foram tomadas, quais mensagens chegaram ao outro lado nem se a chamada estava estável ou ainda em transição. O IUA podia mudar a rota de sinalização; a continuidade da aplicação continuava sendo outra responsabilidade.

O que a norma mudou — e o que não comprova

A RFC 3057 acrescentou à arquitetura SIGTRAN uma adaptação definida para usuários de Q.921. Com isso, o processamento distribuído de chamadas podia usar um backhaul IP sem eliminar a fronteira padronizada com a rede de circuitos. Em 2006, a RFC 4233 a substituiu e refinou a mesma adaptação. Essa sequência documental mostra a evolução do padrão, não quais operadoras o implantaram, quais equipamentos compraram ou quantas chamadas sobreviveram a uma falha real.

A lição de engenharia é mais específica do que dizer que “a telefonia migrou para IP”. Uma fronteira de serviço pode mudar enquanto a interface física continua em outro lugar. Terminação do enlace, adaptação das primitivas, associação de transporte, processo receptor e estado da aplicação necessário para manter uma chamada coerente exigem evidências separadas. Uma associação SCTP restaurada ou um ASP ativo não comprovam que a chamada foi concluída.

Fontes