WirelessBR

Série de artigos sobre VoIP
Quinto artigo - Parte 02

Série VoIP (5) – Sinalização 

(continuação)

SIGTRAN: 

Bom, a partir de agora acho que já dá para (cautelosamente) religar meu headiness index meter[8]... Pronto! 

Uma vez que a sinalização SS7 envolve a montagem de uma rede “superposta” com a rede de circuitos de voz, começou-se a especular sobre a possibilidade de usar uma rede TCP/IP como meio de transporte alternativo para as mensagens SS7, em substituição aos links de tipos B, C e D (e, em menor escala, os links dos tipos A, E e F) 

Os esforços de padronização para esta tarefa levaram à criação do signaling transport working group[9] (SIGTRAN) na IETF. 

O trabalho do SIGTRAN está condensado em várias RFCs, mas a principal delas, RFC 2960 (complementada pela RFC 3309), especifica um novo protocolo de transporte: SCTP (stream control transmission protocol), semelhante ao TCP no propósito de garantir um serviço de transporte confiável (com flow control e error control), mas usando um conceito mais genérico para as conexões entre aplicações, denominados streams. 

A filosofia da arquitetura e transporte de mensagens de sinalização telefônica sobre TCP/IP está descrita em um par de RFCs cuja leitura é mandatória para quem queira iniciar-se neste assunto: architectural framework for signaling transport (RFC 2719) e telephony signaling transport over stream control transmission protocol applicability (RFC 4166). 

O modelo arquitetural proposto pelo SIGTRAN pode ser implementado tanto nos SSPs/SCPs quanto nos STPs, mas as especificações tem uma nítida afinidade com os STPs como local de implementação. A figura 3 mostra como seria um STP dual stack implementando um gateway entre a rede SS7 e o transporte SIGTRAN. 

  Figura 3 – Arquitetura de um gateway SIGTRAN

 Na seleção de fornecedores de gateways SIGTRAN, verifique primeiro quais protocolos SS7 são utilizados na rede telefônica, e certifique-se que o fornecedor implementa as RFCs para as adaptation layers apropriadas ao seu caso. 
Para garantia de QoS no modelo DiffServ[10], associe o tráfego SCTP ao PHB AF41 (alta prioridade de transmissão, baixa prioridade de descarte). 

Embora o modelo SIGTRAN ofereça um início de convivência entre a sinalização SS7 da rede telefônica e a rede TCP/IP, seu objetivo é limitado (tipicamente) apenas à redução de custos no transporte das mensagens SS7 entre STPs. 

Mas, onde nós queremos chegar é algo bem mais abrangente, e envolve uma mudança drástica na própria maneira de construir redes telefônicas (e até mesmo a ITU-T reconhece isto). 

O que nós precisamos, agora, é entender o que são softswitches e o modelo NGN. 

Softswitches e NGN: 

A definição de uma NGN (next generation network), feita pelo study group 13 da ITU‑T[11], é: 

A Next Generation Network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users.

Os destaques em negrito são meus. É particularmente interessante observar como esta definição se alinha (ou choca-se) com as visões da IETF com relação às redes TCP/IP. Para quem estiver interessado em maiores detalhes sobre estas sinergias e divergências, veja as apresentações feitas no ITU-T workshop on NGN in collaboration with IETF[12], ocorrido em maio de 2005. 

No centro destas divergências está a adoção, pela ITU-T, da idéia de um “super mediador de serviços” proposto originalmente pelo 3GPP[13] (third generation partnership project) chamado IMS (IP multimedia subsystem) como parte integral e fundamental da NGN (pensando bem, melhor desligar o headiness index meter de novo). 

Porque o IMS choca-se com a visão do IETF? Porque ele fere um princípio arquitetural básico que orienta todo o trabalho de especificação de protocolos na Internet, chamado end-to-end principle. Em termos simples, este princípio diz que você não deve fazer em uma camada inferior o que pode ser resolvido de forma mais simples e eficiente em uma camada superior. Do jeito que está, a interoperação entre aplicações multimídia já é barroca o suficiente (como veremos depois). A introdução de um middleware obrigatório no meio do caminho (o IMS), além de não necessariamente trazer benefícios concretos aos usuários e provedores de serviços, torna a interoperação ainda mais barroca, e levanta suspeitas de que o real interesse das operadoras na adoção do IMS não é técnica, mas comercial (isolar os usuários dos provedores de serviço, e ficar em posição privilegiada para tarifar uns e outros ao seu gosto). 

Mas para que tudo isto possa se manifestar na prática, existe o problema concreto de como interoperar usuários (majoritariamente do serviço de voz, hoje em dia) entre a rede telefônica tradicional e usuários ou provedores de serviço que já tenham migrado para o ambiente NGN. 

Isto cria a necessidade de um gateway que garanta que as chamadas originadas em um dos lados possam ser corretamente encaminhadas e terminadas do outro lado. Este gateway tem que estar conectado à rede telefônica convencional em um lado, e conectado à rede TCP/IP do outro, e fazer todas as traduções de sinalização e encoding necessárias para a interoperação. Em um ambiente carrier-class, estes gateways são conhecidos como softswitches. 

Inicialmente os projetos de softswitches eram monolíticos. Mas logo foi percebido que havia vantagens em separar e distribuir as funcionalidades em máquinas distintas. Assim, as softswitches são, geralmente, implementadas com dois tipos de elementos, fisicamente distribuídos: os media gateways, responsáveis pelo estabelecimento e manutenção das conexões entre os endpoints; e a softswitch propriamente dita, que abriga o call agent (ou media gateway controller), responsável pelo controle de todos os media gateways subordinados a ela. 

Considerando este cenário de transição, os endpoints podem ser: 

• Aparelhos telefônicos convencionais, fixos ou móveis, conectados aos media gateways por enlaces TDM[14] (PDH/SDH/SONET[15]) típicos dos serviços de transmissão na rede telefônica; 

• Aparelhos PABX (private automatic branch exchange), que podem ter, atrás deles, aparelhos convencionais ou estruturas VoIP corporate, não necessariamente compatíveis com os modelos carrier-class (ex.: skinny); 

• Servidores de aplicação (ex.: voice-mail); 

•  VoIP phones e softphones. Um VoIP phone é um computador construído com a mesma aparência geral de um telefone convencional, especializado em executar apenas uma aplicação – chamadas telefônicas. Um VoIP softphone é uma aplicação capaz de executar chamadas telefônicas, que é executada em um computador de propósitos gerais (ex.: um PC ou um handheld computer); 

• ATAs (analog telephone adapters), para conexão de um ou mais aparelhos telefônicos convencionais.

De forma simplificada, a figura 4 mostra como é o relacionamento, em termos dos fluxos de dados de sinalização e das conexões de voz, entre signaling transfer points SS7 (STP), call agents (CA), media gateways (MG) e endpoints (EP).  

Note que a figura mostra a situação isolada de uma única operadora que deseje migrar sua rede (ou parte dela) para VoIP. Os comentários após a figura irão estender-se mais sobre isto. 

 Figura 4 – Fluxos de voz e sinalização

Com relação às conexões de voz, vemos as seguintes situações: 

• Chamadas originadas e terminadas em endpoints convencionais (TDM), mas com uma parte da rota (entre os media gateways) sendo cursada sobre a rede TCP/IP; 

• Chamadas originadas em um endpoint convencional e terminadas em um endpoint TCP/IP, ou vice-versa. Nestes casos haverá a intermediação de um media gateway no ponto de passagem entre a rede telefônica e a rede TCP/IP; 

• Chamadas originadas e terminadas em endpoints TCP/IP. Nestes casos não há necessidade de intermediação por media gateways.

Cada uma destas situações envolve necessidades distintas de sinalização. As duas primeiras necessitam interação com rede de sinalização SS7 da rede telefônica. A terceira pode, em um primeiro momento, apoiar-se na estrutura de sinalização SS7 convencional (com o uso do SIGTRAN apenas para evitar redes superpostas). Entretanto, como veremos depois, em um cenário onde a disseminação da arquitetura NGN já seja significativa existe a necessidade de algum esquema pós-SS7 para garantir a interoperação entre operadoras diferentes. 

Portanto, podemos dividir o problema da sinalização em três aspectos: 

• Sinalização entre call agent e media gateways, para todas as situações onde um ou mais media gateways estejam envolvidos; 

• Sinalização entre call agent e endpoints, para todos os casos onde pelo menos um dos endpoints envolvidos seja TCP/IP (veremos depois que, nestes casos, aparecem outros componentes de software, mas, por enquanto, a bem da simplicidade, vamos considerá-los associados ao call agent); 

• Sinalização entre call agents, para os casos de conexões que precisam ser estabelecidas entre endpoints que pertençam a domínios administrativos diferentes. 

As próximas três seções irão abordar os protocolos de sinalização existentes para cada uma destas situações.