Série de artigos sobre VoIP (5) - VoIP - Sinalização - Parte 03

WirelessBR		WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações
Série de artigos sobre VoIP (5) VoIP Sinalização - Parte 03
José de Ribamar Smolka Ramos

O primeiro passo que uma operadora de telefonia pode, possivelmente, considerar para introduzir VoIP em sua rede é utilizar softswitches para encaminhar sobre uma rede TCP/IP o tráfego que seria, normalmente, transportado pela rede de transmissão TDM convencional.

Nesta abordagem, o objetivo é apenas redução de custo operacional (OPEX). Os mesmos enlaces TDM serão usados, mas como eles passam a transportar pacotes, e não circuitos, a capacidade de transporte dos enlaces de transmissão aumenta.

A história do desenvolvimento dos protocolos para controle da interoperação entre softswitches e a rede telefônica convencional tem dois capítulos. Em um primeiro momento houveram esforços separados da ITU-T (que defendia uma arquitetura de softswitch monolítica) e do IETF (que propunha uma arquitetura distribuída). Destes dois esforços resultaram duas especificações incompatíveis: a recomendação H.246 e o protocolo MGCP (media gateway control protocol) na RFC 2705.

Tanto a ITU-T quanto o IETF reconheceram a necessidade de criar um padrão comum para interoperação da rede telefônica com softswitches de arquitetura distribuída (call agent + media gateways). Assim, foi estabelecido um working group no IETF chamado MEGACO (media gateway control), que passou a trabalhar em conjunto com o study group 16 da ITU-T.

Deste trabalho conjunto surgiu uma especificação comum para um protocolo de controle do diálogo call agent/media gateways, na forma da recomendação H.248 da ITU-T e da RFC 3015 do IETF. Inicialmente o protocolo ficou conhecido pela mesma sigla do working group IETF: MEGACO, mas, na sua versão mais recente, conforme a RFC 3015, o nome do protocolo é GCP (gateway control protocol).

Então temos a seguinte situação: MGCP e H.248/GCP endereçam o mesmo problema (controle da comunicação entre o call agent e os media gateways subordinados a ele), mas o H.248/GCP são considerados padrões, enquanto o MGCP só é mantido por razões históricas. Não existindo uma base instalada de softswitches antigas baseadas em MGCP, não há motivo para continuar especificando o suporte a este protocolo em novas implementações.

O cenário de comunicação atacado por ambos os protocolos está descrito na figura 5.

A seqüência relevante de eventos para o call setup entre o usuário A e o usuário B (tradicionalmente, em telefonia, A é o originador, e B é o receptor[1]) é:

1. Usuário A tira o fone do gancho, aguarda que a sua central local (onde ele está diretamente conectado) indique que está pronta para receber sinalização (via tom de discar), e digita o número do usuário B;

2. A central local de A, através dos tons DTMF (dual tone multi-frequential) associados aos dígitos recebidos, identifica (via consulta à sua “tabela de rotas”) que a chamada tem de ser encaminhada através da softswitch;

3. A central local de A envia mensagem SS7 (possivelmente, mas não obrigatoriamente, via um ou mais STPs) para o call agent[2], solicitando alocação de canal TDM para encaminhamento da voz;

4. O call agent aloca o canal de voz TDM entre a central local de A e o media gateway mais próximo dela (conforme o roteamento adotado), e seleciona o media gateway mais próximo da central local de B, por onde o canal de voz seguirá adiante.

5. O call agent sinaliza para os media gateways envolvidos, via mensagens H.248/GMP, para que os mesmos efetivem as alocações previstas no passo (4), e determina os parâmetros que devem ser utilizados para os fluxos RTP associados com esta chamada (formato de encoding e portas de transporte UDP a utilizar para os pacotes de voz e para pacotes de transporte de tons DTMF[3]);

6. Os media gateways estabelecem as conexões TDM e RTP necessárias e sinalizam a sua disponibilidade para o call agent, via mensagens H.248/GCP;

7. O call agent envia mensagem SS7 para a central local de B solicitando a alocação do canal de voz TDM para o restante do circuito;

8. A central local de B termina a alocação do circuito e verifica a disponibilidade do terminal B. Se ele estiver disponível, ela envia para o terminal B sinalização de chamada (manda tocar a campainha do aparelho) e envia mensagem SS7 para a central local de A indicando este fato. A central local de A, então, envia para o terminal A tom de chamada. Se o terminal B não estiver disponível (nem houver programação de serviços follow me ou voice-mail associados ao terminal B) a sinalização de terminal indisponível é retornada da mesma forma até o terminal A (na forma de tom de ocupado);

9. Quando o assinante B atende a chamada (retirando o seu fone do gancho), a central local de B sinaliza início de chamada e suas características para o sistema de billing.

A partir deste ponto, a chamada está em andamento (call in progress), e não é difícil imaginar a seqüência de eventos para a desconexão (call teardown).

Um detalhe (que pode tornar-se importante em ambientes multi-vendor) sobre o formato das primitivas do protocolo H.248/GCP. Em grupos de trabalho que redigem normas é comum não haver consenso quanto a um determinado aspecto do padrão. As opiniões polarizam-se em torno de duas (às vezes mais) alternativas, e o processo emperra. Nestes casos, a saída típica é: padronizam-se as duas (ou mais) opções como válidas. No caso do protocolo H.248/GCP ocorreu uma situação deste tipo em relação ao formato de encoding das primitivas. A ITU-T preferia notação ASN.1 (abstract syntax notation 1[4]), e o IETF formato texto ASCII. Resultado: os dois tipos de encoding das mensagens são aceitáveis.

Assim como no caso do SIGTRAN, os pacotes de sinalização H.248/GCP devem ser classificados no PHB AF41, para efeito de garantia de QoS na transmissão sobre uma rede TCP/IP que implemente o modelo DiffServ.

O transporte dos pacotes H.248/GCP pode ser feito sobre TCP ou UDP. Nas implementações práticas que tenho visto, entretanto, há uma nítida preferência pelo UDP.

Obviamente, o modelo de comunicação suportado pelos protocolos MGCP e H.248/GCP é uma transposição simples do modelo tradicional de encaminhamento de chamadas na rede telefônica (inteligência centralizada, terminais burros), e certamente ele é útil para determinadas situações. Mas, embora este modelo possa ser adaptado para o caso onde os endpoints deixam de ser aparelhos (ou servidores de aplicação) convencionais, incrementando as funções de call setup dos call agents, as necessidades genéricas de comunicação multimídia impõem a evolução para algo mais sofisticado, como veremos a seguir.

[1] Curiosidade: A sigla BINA, usada para o sistema de identificação de originação de chamadas pelo receptor, significa “B identifica o número de A”.

[2] Este é um cenário simplificado. Poderiam haver vários elementos intermediários entre a central local de A e o call agent, assim como podem haver vários elementos intermediários, também, entre o call agent e a central local de B no passo (7).

[3] Veja em www.wirelessbrasil.org/wirelessbr/colaboradores/jose_smolka/cod_voz_01.html. Os vocoders híbridos são notoriamente ruins na codificação de qualquer tipo de som que não seja a voz humana. Daí a necessidade de um canal separado para tons DTMF que o usuário pode necessitar para, por exemplo, acessar o front office automático de um call-center, que é comandado por estes tons.

[4] Linguagem formal para especificação não-ambígua de estruturas de dados. Especificação conjunta da ISO e da ITU-T, sua versão mais recente está descrita na série de recomendações X.680 da ITU-T.

WirelessBR