implantação e desenvolvimento de serviços · pdf fileresumo marcondes,...
TRANSCRIPT
IMPLANTAÇÃO E DESENVOLVIMENTO DE SERVIÇOS PARA AMBIENTE HETEROGÊNEO DE TELEFONIA IP
Cesar Augusto Cavalheiro Marcondes
Universidade Federal do Rio de Janeiro Programa de Pós-graduação DCC/IM/NCE
Orientador : Prof. Paulo Henrique de Aguiar Rodrigues
IM/NCE/UFRJ
RIO DE JANEIRO, RJ - BRASIL ABRIL DE 2002
ii
FICHA CATALOGRÁFICA
Marcondes, Cesar Augusto Cavalheiro.
Implantação e Desenvolvimento de Serviços em Ambiente Heterogêneo de Telefonia IP / Cesar Augusto Cava lheiro Marcondes. - Rio de Janeiro, 2002.
viii, 107 f. il.
Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro - UFRJ, Programa de Pós-Graduação em Informática DCC/IM/NCE, 2002.
Orientador: Paulo Henrique de Aguiar Rodrigues 1. Telefonia na Internet. 2. Ambiente Heterogêneo de
Telefonia. 3. Programação de Serviços de Telefonia IP. I. Rodrigues, Paulo Henrique de Aguiar(Orient.) II. Universidade Federal do Rio de Janeiro. Programa de Pós-Graduação em Informática IM/NCEC/UFRJ. III. Título (série).
iii
RESUMO MARCONDES, Cesar Augusto Cavalheiro. Implantação e Desenvolvimento de Serviços para Ambiente Heterogêneo de Telefonia IP. Orientador: Paulo Henrique de Aguiar Rodrigues. Rio de Janeiro: IM/NCE/UFRJ, 2002. Dissertação (Mestrado em Informática). A Internet se tornou o meio de comunicação universal, trazendo inúmeros benefícios para os usuários e tornando a comunicação sobre IP a forma predominante para a transmissão de dados e informação multimídia. Espera-se que, em futuro próximo, a rede de telefonia convencional realize uma completa convergência com a Internet, resultando numa rede única para a transmissão de dados e voz. A telefonia IP vem crescendo muita com este apelo, existem diversas padronizações disponíveis para este novo mercado, como o protocolo SIP da IETF e a recomendação H.323 da ITU-T. Estas padronizações terão que coexistir em um ambiente heterogêneo. Neste trabalho, é apresentada a implantação de um ambiente heterogêneo de telefonia IP (SIP/H.323), desde a sua operacionalização com a escolha dos clientes e servidores de telefonia IP e testes com o grupo VOIP da Internet2, até a proposta de estender ao ambiente heterogêneo a capacidade de programação de serviços telefônicos. Para flexibilidade do ambiente, foi desenvolvido um serviço Web-to-Dial baseado em SIP com segmentador de mensagens robusto e qualidade na transmissão e recepção de mídia, que permite um usuário realizar suas ligações via Web. Para a programação de serviços, foi utilizada uma abordagem que implementa serviços como extensões dos servidores de telefonia IP com uso da linguagem CPL. Esta forma de implementar serviços é simples e genérica, portanto apropriada para o ambiente heterogêneo. Para suportar a programação de chamadas foi desenvolvido um editor de script CPL com interface gráfica e implementado um gatekeeper H.323 com extensão CPL, que possibilita criar serviços de telefonia IP em ambiente H.323, sem o uso de serviços suplementares.
iv
ABSTRACT MARCONDES, Cesar Augusto Cavalheiro. Deployment and Development of Services for IP Telephony Heterogeneous Environment. Advisor: Paulo Henrique de Aguiar Rodrigues. Rio de Janeiro: IM/NCE/UFRJ, 2002. Thesis (Master Science in Computer Science).
The Internet has truly become the ubiquitous communication infrastructure, bringing many benefits to the users and making communication over IP the predominant protocol architecture for data and multimedia transmission. The regular telephone service shall, in a near future, converge to the Internet, giving place to a single integrated voice and data network. IP telephony is growing, following this expected trend, and different protocol standards, as SIP and H.323, are available for this new service. These standards must coexist in heterogeneous environments. In this thesis, we present the deployment of a heterogeneous SIP/H.323 environment, involving the selection, testing and development of IP telephony clients and servers, participation in Internet 2 VOIP WG experiments, and establishment of a framework for programming IP telephony services. To allow a user to place calls while navigating over the net, a Web-to-Dial SIP client was developed based on robust message parser and quality in media transmission. To allow extended features, an approach based on supporting telephony services as CPL language extensions to servers was adopted. This approach being simple and generic is very adequate to our heterogeneous VOIP environment. To facilitate service programming, a CPL script editor with graphical interface was built. A gatekeeper H.323 with CPL extension was also implemented, enabling H.323 IP telephony services without the use of supplementary services.
v
LISTA DE ABREVIATURAS AARNET Australian Research Network JRE Java Runtime Environment ABNF Augmented Backup-Naur Form JVM Java Virtual Machine ACF Admission Confirm LAN Local Area Network ACL Access Control List LRQ Location Reject APDU Application PDU MG Media Gateway API Application Programming Interface MGC Media Gateway Control ASN.1 Abstract Syntax Notation One MGCP Media Gateway Control Protocol BSM Basic Signaling Messages MIB Management Information Base CESNET Czech Research Network MIME Multipurpose Internet Mail Extensions CGI Common Gateway Interface NAT Network Address Translation CNAME Canonical Name PBX Private Branch Exchange CPL Call Processing Language PCM Pulse Code Modulation DFC Distributed Feature Connection PDU Protocol Data Unit DGK Directory Gatekeeper (H.323) PSTN Public Switched Telephone Network DHCP Dynamic Host Configuration Protocol QoS Quality of Service DNS Domain Name System RAS Registration/Admission/Status DSCP Differentiated Services Code Point RFC Request for Comments DTD Document Type Definition ROS Remote Operations Service EBNF Extended Backus-Naur Form RRQ Registration Request FDM Frequency Division Multiplex RTCP Real Time Control Protocol FSMUA Finite State Machine User Agent RTP Real Time Transport Protocol FXO Foreign Exchange Office RTT Round-Trip Time FXS Foreign Exchange Station SDL Specification and Description Language GK Gatekeeper (H.323) SDP Session Description Protocol GNU GNU’s Not Unix SET Simple Endpoint Type GRQ Gatekeeper Request SIP Session Initiation Protocol GW Gateway SMTP Simple Mail Transfer Protocol HTML Hypertext Markup Language SS7 Signaling System 7 HTTP Hypertext Transfer Protocol TCP Transmission Control Protocol HUT Helsinki University of Technology TOS Type of Service IETF Internet Engineering Task Force UDP User Datagram Protocol IMTC International Multimedia
Teleconferencing Consortium URL VOIP
Uniform Resource Locator Voice over IP
IOS Internetworking Operating System XML Extensible Markup Language IP Internet Protocol YACC Yet Another Compiler Compiler ISDN Integrated Services Digital Network ISUP ISDN User Part ITSP Internet Telephony Service Provider ITU-T International Telecommunication
Union
JAIN Java API Integrated Networks JAR Java Archive JMF Java Media Framework JNI Java Native Interface
vi
LISTA DE FIGURAS Figura 1 – Um exemplo do funcionamento da rede virtual Eclipse Figura 2 – Interação de Serviços sob o Ponto de vista do Ambiente Heterogêneo Figura 3 – Decisão sobre liberar os recursos usando Certificado Auto-Gerado Figura 4 – Implementação UFRJ SIP Client Figura 5 – Diagrama de Classes do Módulo de Transporte da Sinalização SIP Figura 6 – Diagrama de Classes do Módulo de Geração de Mensagens SIP Figura 7 – Gerenciamento da Máquina de Estados SIP Figura 8 – Classes de Transmissão e Recepção de Áudio Figura 9 – Utilização do JMF Registry para habilitar captura de áudio pela Applet Figura 10 – Arquitetura do Laboratório VOIP/UFRJ Figura 11 – Interfaces FXS e FXO Figura 12 – Novas características do H.323 v4.
(A) Procedimento de uso de gatekeepers alternativos; (B) Endpoints podem relatar sua capacidade aos GKs (C) Decomposição do Gateway com H.248.
Figura 13 – Programa openphone em execução Figura 14 – Diagrama de Classes do Opengatekeeper Figura 15 – Diagrama de Classes do OpenGK Figura 16 – Arquitetura de Telefonia IP do Laboratório VOIP Figura 17 – Problema de Location Request entre Sites VOIP da Internet2 Figura 18 – Configuração do Grupo VOIP Internet2 Figura 19 – Serviço Suplementar Call Transfer H.323
(A) Serviço Suplementar Call Transfer e (B) Implementação de Call Transfer no OpenPhone
Figura 20 – Editor Gráfico de CPL e Gerador do XML correspondente ao grafo CPL Figura 21 – Diagrama de Classes da Parte Gráfica do Editor CPL Figura 22 – Diagrama de Classes da Parte XML do Editor CPL Figura 23 – Instalador CPL para Ambiente H.323 Figura 24 – Diagrama de Classes das Mensagens RAS/H.225 Figura 25 – Diagrama de Classes do GK com Extensão CPL Figura 26 – Fluxo Básico do Redirecionamento por Endereço (h323- id)
vii
LISTA DE QUADROS Quadro 1 – Diferenciação da mensagem SIP através do Parsing da primeira linha Quadro 2 – Trecho do Código da Montagem da mensagem ACK com NIST-SIP Quadro 3 – Trecho do Código em Java da Sequencia de Captura de Áudio e
Transmissão via RTP Quadro 4 – Callback da Classe AudioReceive do SIPApplet para capturar mudança
de payload Quadro 5 – Entrada DNS SRV para SIP do laboratório VOIP com distribuição de
carga Quadro 6 – Configuração Básica do Roteador Cisco 2600 para Suporte SIP Quadro 7 – Mensagem de Status SIP do Cisco 2600 obtida com o comando: debug
ccsip all Quadro 8 – Configuração do Opengatekeeper Local Quadro 9 – Trecho do Log do Opengatekeeper usado para calcular o tempo da
ligação Quadro 10 – Configuração das Interfaces e Planos de Discagem do Gateway Cisco
2600 Quadro 11 – Configuração da Interface Gateway para Registro no GK Quadro 12 – Configuração dos Dial-peers da Internet2 Quadro 13 – Tabela de Serviços Suplementares H.323 Quadro 14 – Exemplo de Script CPL de Roteamento pela Hora do Dia Quadro 15 – Diferenças para os nós Incoming e Outgoing Quadro 16 – Diferenças para os nós Address-Switch contendo parâmetro field Quadro 17 – Diferenças pra os nós Address-Switch contendo parâmetro sub-field Quadro 18 – Diferenças para os nós String-Switch contendo parâmetro field Quadro 19 – Diferenças para os nós Location contendo parâmetro url Quadro 20 – Diferenças para os nós Lookup Quadro 21 – Trecho do Código de verificação se o campo GatekeeperIdentifier tem o
mesmo ID do GK Quadro 22 – CPL/XML de Serviço de Redirecionamento por Endereço
viii
LISTA DE TABELAS Tabela 1 – Resultados do Uso do Montador de Mensagens NIST-SIP em
comparação com o montador de mensagens simplificado da implementação SIP Applet (AMD K7/256 MB RAM/média de 30 experimentos)
Tabela 2 – Resultados de cinco observações dos testes no Cenário 1 de Interoperabilidade entre Clientes SIP (Ponto-a-Ponto) (segundo IMTC)
Tabela 3 – Resultados de cinco observações dos testes nos Cenários 2, 3, 4 de Interoperabilidade entre Cliente SIP e Servidor SIP (segundo IMTC)
SUMÁRIO
CAPÍTULO 1 - INTRODUÇÃO.............................................................................................................................2
1.1 – REVISÃO DOS PROTOCOLOS DE SUPORTE A TELEFONIA DA INTERNET ..................................................2 1.2 – A TELEFONIA IP .............................................................................................................................................3 1.3 – PROTOCOLOS SIP, H.323 E MGCP..............................................................................................................5 1.4 – AMBIENTE HETEROGÊNEO DE TELEFONIA IP.............................................................................................7 1.5 –SERVIÇO WEB-TO-DIAL..................................................................................................................................8 1.6 –IMPLANTAÇÃO DE AMBIENTE H.323..........................................................................................................10 1.7 – INTRODUÇÃO À PROGRAMAÇÃO DE SERVIÇOS NO AMBIENTE HETEROGÊNEO...................................11 1.8 – FRAMEWORK DE PROGRAMAÇÃO DE SERVIÇOS PARA AMBIENTE HETEROGÊNEO ............................13 1.9 – PROGRAMAÇÃO DE SERVIÇOS USANDO PARLAY/DFC ...........................................................................14 1.10 – COMPARAÇÃO ENTRE PROGRAMAÇÃO DE SERVIÇO USANDO PARLAY/DFC E AMBIENTE HETEROGÊNEO........................................................................................................................................................15 1.11 – ORGANIZAÇÃO DA DISSERTAÇÃO............................................................................................................18
CAPÍTULO 2 - IMPLEMENTAÇÃO DE CLIENTE SIP ROBUSTO BAS EADO NA WEB E IMPLANTAÇÃO DO AMBIENTE SIP NO LABORATÓRIO VOIP..................................................... 19
2.1 – OPÇÃO PELO USO DO JAVA PLUGIN...........................................................................................................19 2.1.1 – Trabalhando com Applets Assinadas para acessar Serviços Remotos de Rede................... 20
2.2 – DETALHAMENTO DOS MÓDULOS DO CLIENTE SIP USANDO APPLET ...................................................21 2.3 – SEGMENTADOR DE MENSAGENS GERADO PELA GRAMÁTICA SIP ABNF...........................................26 2.4 – CAPTURA DE MÍDIA PELO BROWSER.........................................................................................................29
2.4.1 – Detalhamento do Módulo de Transmissão e Recepção de Áudio RTP ................................. 30 2.4.2 – Questões de Desempenho do Pacote JMF Performance Pack................................................ 32
2.5 – TESTES DE CONFORMIDADE ENTRE IMPLEMENTAÇÕES SIP ..................................................................34 2.5.1 – Problema da Interoperabilidade dos Fluxos de Mídia entre Gateway SIP/PSTN (Cisco 2600) e Java Media Framework (JMF)..................................................................................................... 36
2.6 – IMPLANTAÇÃO DE AMBIENTE DE TELEFONIA IP BASEADO EM SIP......................................................38 2.6.1 – Configurações do Gateway SIP/PSTN Cisco 2600.................................................................... 40
CAPÍTULO 3 - IMPLANTAÇÃO DE AMBIENTE H.323 E TESTES DE INTEROPERABILIDADE DE VOZ SOBRE IP NA INTERNET2 ......................................................... 43
3.1 – EVOLUÇÃO DA RECOMENDAÇÃO H.323...................................................................................................43 3.2 – PESQUISA SOBRE OS PROGRAMAS DO PROJETO OPENH323....................................................................46
3.2.1 – Implantação e Testes das Ferramentas H.323 no Laboratório VOIP ................................... 48 3.2.2 – Estudo sobre Gatekeepers H.323 baseado no OpenH323 ........................................................ 48 3.2.3 – Implantação de Ambiente H.323 no Laboratório VOIP ........................................................... 53 3.2.4 – Logando Ligações no Ambiente UFRJ ........................................................................................ 55
3.3 – IMPLANTAÇÃO DO GATEWAY H.323/PSTN CISCO 2600.......................................................................56 3.3.1 – Configurações Iniciais do Roteador Cisco 2600 ........................................................................ 57
3.4 – INTEROPERAÇÃO OPENGATEKEEPER E GATEWAY H.323/PSTN CISCO ..............................................58 3.4.1 – Configuração de Dial-Peer para os Sites de VOIP da Internet2 ............................................ 59
3.5 – TESTES DE INTEROPERAÇÃO COM SITES VOIP DA INTERNET 2.............................................................61 3.5.1 – Considerações sobre a Confiabilidade e Escalabilidade do Ambiente VOIP H.323 da UFRJ ................................................................................................................................................................. 64 3.5.2 – Considerações sobre a Segurança do Ambiente VOIP H.323 da UFRJ............................... 64
CAPÍTULO 4 - PROGRAMAÇÃO DE SERVIÇOS DE TELEFONIA IP ............................................. 66
4.1 – SERVIÇOS AVANÇADOS H.323 DE TELEFONIA IP....................................................................................66 4.2 – DEFINIÇÃO DA LINGUAGEM DE PROCESSAMENTO DE CHAMADA (CPL).............................................70
4.2.1 – Mapeamentos entre o comportamento da CPL de SIP para H.323 ....................................... 72 4.3 – IMPLEMENTAÇÃO DE EDITOR CPL............................................................................................................74
4.3.1 – Gerenciamento da Parte Gráfica do Editor CPL ....................................................................... 76 4.3.2 – Gerenciamento da Parte de Manipulação XML......................................................................... 77 4.3.3 – Utilizando Serviço Web para Gatekeeper..................................................................................... 79
4.4 – IMPLEMENTAÇÃO DE GATEKEEPER COM EXTENSÃO CPL .....................................................................80 4.4.1 – Módulo de Manipulação CPL-XML do Servidor....................................................................... 83 4.4.2 – Exemplo da Execução de Script CPL pelo Servidor.................................................................. 84 4.4.3 – Impacto do CPL para a Escalabilidade do GK ........................................................................... 87
CAPÍTULO 5 - CONCLUSÕES E TRABALHOS FUTUROS .................................................................. 89
REFERÊNCIAS ....................................................................................................................................................... 94
ANEXO 1 - AMBIENTE SIP ..............................................................................................................................101
ANEXO 2 - AMBIENTE H.323 .........................................................................................................................105
CAPÍTULO 1
INTRODUÇÃO
A telefonia (Rede de Telefonia Pública de Comutação por Circuitos, ou PSTN),
nos últimos anos, tem experimentado uma enorme mudança estrutural. Ao invés da
utilização de circuitos comutados (tecnologias TDM/FDM) para o transporte de voz,
tem-se buscado tecnologias baseadas na comutação de pacotes, como a da rede Internet
(IP), tipicamente uma rede de dados, para prover as telecomunicações. Entre as
vantagens desta reengenharia podemos citar a possibilidade de uma melhor utilização
dos meios físicos devido à multiplexação estatística e à viabilidade do transporte
integrado de dados, vídeo e voz sob a mesma infra-estrutura.
O futuro das telecomunicações está nesta convergência das redes de dados e de
voz. Cabe à Internet, candidata a ser esta rede convergente dada a sua ubiqüidade, ter o
suporte necessário à substituição da telefonia. Para alcançar tal objetivo, ela deve ser
capaz de prover qualidade de serviço às comunicações, realizar transmissões de fluxos
de áudio em tempo real, e estruturar uma arquitetura de sinalização apropriada.
1.1 – Revisão dos Protocolos de Suporte a Telefonia da Internet
O grupo de engenharia da Internet (IETF) tem trabalhado em mudanças nos
protocolos da arquitetura Internet visando obter tal convergência. Um exemplo destas
mudanças, para prover qualidade de serviço, foi a revisão do cabeçalho Type of Service
(TOS) do protocolo IP, que foi projetado para rotular os pacotes IP de modo a terem
diferentes prioridades nas filas dos roteadores da Internet, dependendo do tipo de
serviço associado à esses pacotes. Desse modo um fluxo de voz teria maior prioridade
nestas filas do que outros. O cabeçalho foi remodelado com o nome de Differentiated
3
Services Code Point (DSCP), para prover classes de serviço diferenciadas para o tráfego
da Internet [1].
A IETF também criou um novo protocolo de suporte à transmissão de
multimídia em tempo real na Internet chamado Real Time Transport Protocol (RTP)
[2]. O RTP implementa o seqüenciamento dos pacotes UDP na transmissão da mídia,
para que eles possam ser recuperados no destino na ordem correta. Além disso, descreve
em seus cabeçalhos, o tipo de codificador e a taxa de amostragem que está sendo usada
na mídia transmitida; e sincroniza o destino com a fonte multimídia através de
marcações de tempo nos pacotes. Atuando em conjunto com o RTP, também foi
desenvolvido o Real Time Control Protocol (RTCP), que envia à fonte RTP relatórios
dos parâmetros da qualidade de serviço (QoS) experimentada na transmissão (como a
fração de pacotes perdidos e a variação de atraso entre pacotes).
O outro desafio dos requisitos de convergência é a montagem da arquitetura de
sinalização. Entende-se por arquitetura de sinalização, como a forma de realizar a
localização de endereços e o estabelecimento de chamadas na telefonia. No caso da
telefonia convencional é preciso conhecer previamente o número telefônico da pessoa a
ser chamada, e então enviar a sinalização de estabelecimento de chamada até o telefone
destino. No caso da Internet, no primórdios das pesquisas de transmissão de voz, não
tínhamos esta característica de sinalização. Para estabelecer uma comunicação na rede
era preciso combinar previamente por email, quais endereços IPs e portas de origem e
destino seriam utilizados. Mas este paradigma mudou ao surgirem protocolos capazes
de estruturar esta arquitetura de sinalização como o Session Initiation Protocol (SIP) [3]
e o H.323 [4] (vide Anexo 1 e 2). Estes protocolos permitem realizar a localização de
nomes e/ou números telefônicos e fazer toda a sinalização de chamada, de modo a
mapear transparentemente os endereços IP e portas de comunicação de origem e destino
das partes envolvidas na ligação.
1.2 – A Telefonia IP
Unindo-se os componentes de suporte à telefonia padronizados para a Internet,
obtemos a infra-estrutura de telecomunicações chamada de telefonia IP, que está
redefinindo as relações de comunicação de pessoas e empresas na Internet, tendo como
características:
4
Mobilidade pessoal:
Capacidade de realizar a chamada IP sem saber previamente o endereço IP de
um usuário. À medida que o usuário chamado mudar de posição (por ex.: rede
celular), ou trocar seu endereço IP (por ex.: Dynamic Host
Configuration/DHCP), ele automaticamente vai alterando seus registros, de
modo que ao buscarmos este usuário pelo nome, sempre teremos a sua
localização mais atual;
Segurança nas Comunicações:
Com o uso do RTP, a comunicação fica bem mais segura pois podemos
criptografar todo o fluxo multimídia, inutilizando grampos telefônicos;
Independência da Mídia sendo Usada:
Um telefone IP poderia anunciar quais as mídias (áudio e/ou vídeo) que ele
gostaria de usar na ligação. Após uma negociação apropriada feita pela
sinalização (SIP ou H.323) é escolhida a opção de mídia comum entre os
telefones IPs envolvidos. Desse modo, se uma das partes não tiver suporte à
recepção de vídeo, por exemplo como é o caso de um aparelho telefônico com
capacidade IP, apenas o canal de áudio será utilizado nesta ligação;
Serviços:
Na telefonia convencional é possível programar serviços, na central telefônica,
para mudar o comportamento do estabelecimento da chamada. Um exemplo
destes serviços seria o Call Forward On Busy. Ele roteia a chamada para outro
telefone, toda vez que, o telefone chamado estiver ocupado. Isso também pode
ser feito na telefonia IP, com uma importante diferença: a convergência. Um
provedor Internet, interessado em diferenciar seus serviços de telefonia IP, pode
criar aplicações agregadas a estes serviços. Para se ter uma idéia deste tipo de
aplicação, imaginemos um serviço de dados como o email. Agregando-se a ele
uma secretária eletrônica ligada à rede telefônica, temos um novo tipo de caixa
postal de mensagens de voz, que envia as mensagens gravadas para o email do
usuário. Se agregarmos em seguida um componente Web, então este usuário
poderá ter acesso a sua caixa postal via webmail, e assim por diante. Rosenberg
em [5] estabelece um teorema onde diz que o conjunto de características e
5
serviços que um certo provedor pode fornecer aumenta exponencialmente com o
número de aplicações que podem ser agregadas.
Preço:
A diminuição ou eliminação de custo nas ligações de longa distância na telefonia
IP é um fator complementar desejável e que surgirá com a implantação em larga
escala de ambientes de telefonia IP.
Confiabilidade:
Quanto a essa característica, a telefonia IP ainda está longe de ultrapassar a
excelente confiabilidade da PSTN (a literatura refere-se a confiabilidade da
PSTN como 99,999%, enquanto que a Internet estaria em 99% a 99,5%). Atingir
esta meta é um problema difícil, pois não adianta apenas mudar os protocolos; é
preciso realizar um atualização completa de hardware/software da rede em
funcionamento. No caso da telefonia IP em particular, o que dificulta ainda mais
é o fato de que ela precisa de um número elevado de componentes diferentes
para funcionar, incluindo gateways, servidores, DNS e DHCP, cada um destes
sujeitos a falhas independentes.
1.3 – Protocolos SIP, H.323 e MGCP
Um dos grandes desafios enfrentados atualmente para a implantação em larga
escala da telefonia IP é o problema da interoperabilidade entre os seus padrões de
sinalização (SIP e H.323). Como não existe um só padrão, uma instituição pode adotar
uma solução incompatível com a de outra com a qual deseja se comunicar. Sabemos que
na rede de telefonia convencional (PSTN) isso não acontece, pois é possível interoperar
sem problemas com a rede de telefonia celular. Para que a telefonia IP se torne universal
é necessário realizar a interoperação entre estes diferentes padrões de telefonia IP, além
da interoperação típica com a rede PSTN, tanto fixa quanto celular.
Existem atualmente três padrões usados para a sinalização da telefonia IP: o
Session Initiation Protocol (SIP) [3], o H.323 [4] e o Media Gateway Control Protocol
(MGCP) [6].
O protocolo SIP, padronizado pela IETF, tem uma excelente integração com o
ambiente Internet, possuíndo as características fundamentais dos protocolos HTTP
(Web) e SMTP (email) como:
6
Mime-type:
O mime (multipurpose internet mail extension) [7] é o padrão usado para
descrever todos os tipos de conteúdos encapsulados em mensagens na Internet.
Logo as mensagens SIP podem conter imagens, arquivos de som ou dados
adicionais.
Url:
As urls (universal resource locator) são a forma universal de endereçamento e
de acesso à aplicações na Internet. Ao invés de ser definido algum novo tipo de
espaço de endereçamento, o SIP usa somente urls para endereçar.
Dns:
O dns (Domain Name System) é o serviço de diretório global usado na Internet
para traduzir os nomes dos domínios em endereços IP. Ao invés de inventar
novos mecanismos para realizar o encaminhamento das chamadas via SIP, usa-
se o mesmo modelo do sistema de email.
Maiores detalhes sobre o funcionamento do SIP estão descritos no Anexo 1.
A recomendação H.323 da International Telecommunications Union (ITU-T) é o
padrão mais próximo da telefonia convencional, tendo surgido do encapsulamento das
mensagens de sinalização da rede ISDN (Rede Digital de Serviços Integrados) para
conferências multimídia em uma rede local (LAN). Posteriormente foi estendida para a
Internet e atualmente é o principal padrão implantado e com maior número de produtos.
Maiores informações sobre o H.323 estão descritos no Anexo 2.
O MGCP [6] é um padrão feito em parceria pela ITU-T e IETF, tratando-se de
um protocolo de controle, que permite a um coordenador central monitorar eventos em
troncos de telefonia e instruir estes a enviar mídia para endereços específicos. A
demanda do MGCP é prover serviços de telefonia IP principalmente para as operadoras
telefônicas.
7
1.4 – Ambiente Heterogêneo de Telefonia IP
Apesar das diferenças verificadas entre os protocolos de telefonia IP, existe um
conjunto de funções básicas realizadas por todos eles, como localização de usuários,
estabelecimento de chamadas, negociação de mídias e finalização de chamadas. Os
protocolos de sinalização têm, portanto, um núcleo lógico comum. Uma forma simples
de concretizar uma arquitetura de telefonia IP heterogênea, isto é, suportar a
convivência de vários protocolos, é pelo uso de gateways de sinalização. Gateways são
dispositivos que fazem a tradução das mensagens entre dois ou mais protocolos e
promovem a interoperação das arquiteturas.
Uma plataforma heterogênea é a que permite, por exemplo, a convivência
simultânea com interoperação de dispositivos e programas, tanto H.323 quanto SIP, na
mesma rede. Ela flexibiliza a escolha da solução pelos usuários, permitindo a eles
adotar a combinação que for mais conveniente.
Foi desenvolvido, numa etapa anterior a este trabalho, um protótipo de gateway
para protocolos SIP e H.323 [8]. Foram usadas como base do mesmo, duas
implementações destas pilhas de protocolos: a do protocolo SIP, escrita em Java e
referenciada em [9], foi cedida como parte da parceria entre a Universidade Tecnológica
de Hensinki (HUT) e a UFRJ, e a do protocolo H.323, escrita em C++, foi obtida
livremente no site do projeto Opengatekeeper [10] desenvolvido pela empresa Egoboo.
O papel do gateway SIP/H.323 não é simplesmente o de traduzir mensagens. Foi
preciso resolver alguns problemas estruturais, seguindo a metodologia, descrita por
Singh e Schulzrinne em [11], para a interoperação das arquiteturas SIP e H.323. Entre
estes problemas temos: a forma diferente de endereçamento usada pelos dois padrões; o
local de armazenamento dos registros de usuários; e o processo de negociação de mídia
que acontece em fases diferentes no SIP e H.323.
O projeto deste gateway opta pela representação das primitivas mais simples dos
protocolos de sinalização por um grupo de mensagens denominado BSM (Basic
Signaling Messages). Assim, as mensagens de estabelecimento de chamada, negociação
de mídia e finalização podem ser trocadas entre SIP e H.323. Esta característica pode
ser estendida, inclusive, para outros protocolos como o MGCP e até protocolos de
telefonia convencional como o SS7, que possuam o núcleo comum.
8
Como a arquitetura heterogênea é baseada na conversão das mensagens mais
básicas de sinalização de cada protocolo, o gateway acaba eliminando os recursos mais
avançados da sinalização, pois ele não suporta o mapeamento de mensagens específicas
de cada protocolo. Normalmente, estas mensagens específicas não estão associadas ao
núcleo básico, mas sim a características de serviços, como os serviços suplementares
H.323 [12].
1.5 –Serviço Web-to-Dial
Em meados de 2001, como contra-partida da parceria com a HUT, nos
comprometemos a prover maior aderência ao padrão SIP no cliente desenvolvido por
eles [13]. Durante o desenvolvimento do gateway SIP/H.323 adicionamos a este cliente
SIP HUT (apelidado de IPTele) novas características, como o suporte a certas
funcionalidades de servidor tais como o gerenciamento de múltiplas threads de
recepção de mensagens SIP. No entanto, percebemos alguns problemas de
interoperabilidade com outros clientes e servidores SIP, pela falta de robustez do
segmentador (parser) de mensagens SIP. Para nós a evolução deste cliente estava
comprometida por estes fatores, levando-nos à decisão de reescrever do zero um novo
cliente SIP.
Este novo cliente SIP, diferentemente do IPTele que é executado como uma
aplicação Java, utiliza a abordagem de distribuição de software pela Internet através do
uso de Java Applets [14]. É importante ilustrar que com o aumento de popularidade e
funcionalidade da telefonia IP, nossos browsers Web gradativamente assumirão o papel
de agentes de comunicação assim como são agentes de informação. O Netscape é um
exemplo. Ele já incorpora um telefone IP Net2Phone® e um agente de comunicação
AOL® de mensagens instantâneas na sua distribuição. Em pouco tempo, o uso da
telefonia estará completamente incorporado a eles. Consequentemente, usuários fazendo
o uso de browsers poderão realizar chamadas tanto para outros usuários na Internet,
quanto na rede telefônica convencional (fixa ou celular). Por isso, a escolha de Java
Applet é especialmente apropriada para um cliente.
Outra vantagem desta escolha é que um software de telefonia IP agregado a uma
página Web oferece uma enorme flexibilidade. Do ponto de vista do usuário, ele
poderia acessar um telefone deste tipo de qualquer local, mesmo em viagens, e realizar a
9
ligação diretamente da Internet. Do ponto de vista do provedor, este poderia montar
uma central de atendimento ao cliente totalmente voltado para a Internet, sem a
necessidade da aquisição de um serviço 0800. Assim o consumidor navegando nas
páginas Web, ao sentir a necessidade de falar com um atendente para sanar eventuais
dúvidas, necessitaria de apenas um clique para ativar o link com a telefonia IP. Outras
vantagens incluem o gerenciamento inteligente de usuários pelo uso de mecanismos de
autenticação, facilidades de atualização online da versão do software e descoberta
automática de bugs, que poderiam ser enviados pela Internet aos desenvolvedores.
Este tipo de implementação não é exclusividade nossa, várias empresas
chamadas de Internet Telephony Service Providers (ITSPs, como por exemplo,
Net2Phone® e Dialpad®, provedores que oferecem serviços de voz sobre IP), já
desenvolveram implementações semelhantes a este cliente baseado em Applet,
chamando comumente este serviço de Web-to-Dial. O diferencial entre nossa
implementação e as mantidas pelos ITSPs é que normalmente estes provedores usam
seus próprios backbones e pontos de gatewaying com a telefonia convencional e não
necessitam (nem desejam por motivos financeiros) utilizar nenhuma sinalização de
telefonia IP. Tendo um mecanismo de escolha de conexão proprietária, ponto-a-ponto,
entre o cliente e o gateway mais otimizado para certa ligação com a telefonia
convencional, sem se preocupar com a liberdade de escolha provida pela telefonia IP.
Nossa implementação, no entanto, é um cliente SIP completo totalmente livre para
escolher com qual gateway SIP/PSTN interoperar, ou em qual servidor SIP se registrar.
Ele funcionaria como um telefone público para a Internet pública.
Além deste serviço Web-to-Dial, partimos para a implantação de uma
arquitetura completa baseada em SIP envolvendo o uso de servidores e gateways SIP e
cobrindo diversos aspectos como escalabilidade, segurança e interoperação com a rede
telefônica. Esta interoperação foi possível através do uso de um gateway SIP/PSTN da
família de roteadores Cisco 2600 [15].
10
1.6 –Implantação de Ambiente H.323
Uma vez montado o ambiente SIP, trabalhamos também na implantação de um
ambiente H.323. O objetivo era ter no laboratório, os dois ambientes SIP e H.323
rodando em paralelo. Posteriormente seria possível integrá- los com o Gateway
SIP/H.323 para obter o ambiente heterogêneo de telefonia IP.
A implantação do ambiente H.323 foi feita de forma gradual, iniciando com o
estudo das recomendações do H.323 e escolha do software gatekeeper (GK)
(responsável pelo registro de usuários e admissão de chamadas) dentre as
implementações de código fonte aberto disponíveis [10][16][17]. Foram realizados
testes e análises de logs para descobrir comportamentos e aderência aos padrões dessas
várias implementações.
Logo depois, foi criada uma infra-estrutura gerencial contendo outras duas zonas
administrativas H.323 (entende-se por zona administrativa a área controlada por um
mesmo GK): uma no laboratório de Vídeo sob Demanda da UFMG, e outra no Network
Research Laboratory da UCLA, EUA. Realizamos testes de localização de usuários
entre estas três zonas administrativas (incluindo a UFRJ) usando o gatekeeper escolhido
na fase anterior.
A última fase de implantação e testes do ambiente H.323 foi na interoperação
com outros sites de telefonia IP do grupo VOIP da Internet2. Para a sua realização,
contamos com o equipamento roteador Cisco 2600 emprestado pela Rede Nacional de
Pesquisa (RNP2) para a condução destes testes. O mesmo roteador utilizado
anteriormente nos testes com o ambiente SIP.
Atualmente, a recomendação H.323 é a que tem sido adotada pelo grupo VOIP
da Internet2 para estruturar uma rede mundial de telefonia IP entre as universidades e
instituições de pesquisa. No caso da Internet2, estas universidades e instituições
envolvidas, em geral, têm usado roteadores Cisco com interfaces de telefonia e IOS
(Internetworking Operationg System, o S.O. do roteador) suportando H.323, para prover
conectividade de voz sobre IP (VOIP).
Estes roteadores da Internet2 podem ser estruturados de uma forma hierárquica
em “Zonas Administrativas”, sendo cada “Zona Administrativa”, uma região gerenciada
por um GK responsável por um grupo de gateways ligados à rede PSTN. O grupo VOIP
da Internet2 demonstrou interesse em organizar zonas administrativas por continente ou
11
país, para rotear chamadas entre sites de telefonia IP. Entretanto, para isso é preciso que
cada GK tenha a capacidade de dar prosseguimento a busca de números telefônicos
numa cadeia de GKs, caso não encontre este número localmente, chamamos este
procedimento de busca multihop. O equipamento sendo usado para tal nível de
organização é o GK Cisco operando como Directory Gatekeeper (DGK) [18]. Contudo
pode haver limitação no uso desta hierarquia, quando no caminho de busca tivermos um
GK que não suporte esta característica.
1.7 – Introdução à Programação de Serviços no Ambiente Heterogêneo
Como vimos na Seção 1.2, a programação de serviços é uma característica
importante no desenvolvimento da telefonia IP, e chave para os provedores que querem
se diferenciar.
Os protocolos de sinalização, sejam SIP ou H.323, podem prover serviços de
programação de chamada, como o Call Forward on Busy (exemplo da seção 1.2), pelo
uso de mensagens específicas do protocolo. Tais mensagens estão fora daquele núcleo
comum de sinalização básica, impossibilitando nossa implementação de gateway
SIP/H.323 de atuar.
Por outro lado, também é possível através do uso de servidores SIP e H.323,
abrigar e executar serviços avançados de programação de chamadas através da alteração
de comportamento no servidor, sem necessidade do uso das mensagens de sinalização
específicas, o que é apropriado ao ambiente heterogêneo de telefonia IP proposto.
Segundo Rosenberg [19] existem duas formas de reprogramar dinâmicamente os
servidores de telefonia IP. A primeira seria pela criação de serviços por usuários ditos
confiáveis, como os administradores de rede, através do uso de CGIs de telefonia IP
(equivalente ao CGI de programação Web). A segunda pela criação de serviços por
usuários não-confiáveis, ou seja, quaisquer outros usuários, através da inserção no
servidor de scripts de redirecionamento de chamadas escritos em CPL.
A CPL [20], ou linguagem de programação de chamada, é um documento XML
[21] que contém, em suas marcações (tags), um grafo de decisões a serem tomadas, de
acordo com o estado de uma ligação. Toda vez que inserimos o pseudo-algoritmo
definido pela CPL no servidor, estamos definindo como o servidor deve tratar as
mensagens de sinalização para prover aquele serviço. Assim, um módulo estendido CPL
12
contendo uma lógica de serviço poderia ser adicionado a um servidor de telefonia IP,
operando independentemente da sinalização, e, baseado nesta lógica, seriam ditadas
como as requisições de chamada deveriam ser redirecionadas, contemplando a
especificação deste CPL.
Como o script CPL escrito em XML [21] é genérico e mantém a semântica para
qualquer arquitetura seja ela SIP ou H.323 conforme mencionado em [20], ele permite a
viabilidade de serviços, desenvolvidos pelos usuários, ultrapassem os limites de uma
única arquitetura de telefonia IP. Isto justifica nossa escolha por usar esta abordagem na
implementação de nosso ambiente heterogêneo. O exemplo a seguir mostra como esta
programação de serviço funciona: Se o usuário A no contexto SIP, quisesse acessar um
outro B no contexto H.323. Caso o usuário B tenha instalado previamente um serviço de
Call Forward on Busy em CPL no GK (H.323), quando A iniciasse o processo de
sinalização SIP, este seria traduzido por nosso gateway SIP/H.323, que enviaria a
sinalização H.323 para o servidor GK de B. Este GK, estendido para usar CPL, faria a
reprogramação de seu comportamento, redirecionando a chamada para outro telefone IP
diferente de B.
Atualmente, entretanto, a definição da CPL limita seu uso apenas ao re-
roteamento passivo de chamadas, ou seja, o processamento do script CPL só ocorre na
fase de estabelecimento da chamada. Outro ponto negativo no uso de scripts CPL é o
acesso restritivo aos recursos computacionais pois eles não trabalham diretamente com
as linguagens de programação e sim com marcações (tags) XML pré-programadas, o
que no modelo de programação CGI não aconteceria. Minimizando estas restrições,
Rosenberg [22] criou em conjunto com a equipe da DynamicSoft® (EUA) uma extensão
do CPL com maior flexibilidade e poder de reprogramação dos servidores de telefonia
IP (baseados em SIP). Esta extensão chamada CPL+ tem como foco a criação de scripts
CPL administrativos. Contudo, estas novas tags presentes no CPL+ não são
padronizadas, sendo mais um recurso de especialização dos produtos da DynamicSoft®,
portanto não utilizamos elas em nossa abordagem, mas demonstram que o é possível
minimizar esta restrição.
13
1.8 – Framework de Programação de Serviços para Ambiente Heterogêneo
Tendo optado pela abordagem de reprogramação dinâmica de servidores por
scripts CPL para nosso ambiente heterogêneo como visto acima, implementamos um
framework CPL desde a criação (editor CPL), instalação (uploader CPL) e
processamento de scripts (extensão CPL para gatekeeper) no ambiente H.323. No caso
do ambiente SIP, já existiam ferramentas de extensão CPL desenvolvidas para o
servidor SIP da Universidade de Columbia, EUA [23]. Logo, usando estes dois
conjuntos de ferramentas, provemos ao ambiente heterogêneo de telefonia IP à
capacidade de realizar programação de serviço de forma genérica.
Lennox descreve o framework CPL e seus requisitos em [24]. Para ele é
importante popularizar a criação de scripts de programação de chamada, de modo a
permitir que os usuários sem experiência, nem com XML, nem com a sintaxe do CPL,
consigam programar seus serviços. Atendendo a estes requisitos, implementamos um
editor gráfico CPL baseado em java applets. Com este editor, o usuário trabalha com a
representação gráfica dos nós CPL desenhando o grafo que imaginar. E depois gerar
automaticamente a representação CPL-XML correspondente.
O processo de instalação do serviço CPL no ambiente H.323, pode ser feito
através de um upload HTTP, enviando o serviço CPL para o servidor H.323 estendido.
O uso de HTTP (sinalização fora do contexto do H.323) é uma necessidade, visto que o
H.323 não suporta mime-types [7] em suas mensagens de protocolo. Esse fato
impossibilita o transporte do script CPL nas mensagens dos protocolos RAS/H.225
(vide Anexo 2), diferentemente do que acontece com o SIP, que pode usar a mensagem
de sinalização REGISTER para transportar o script CPL [25].
Implementamos um uploader que valida o documento CPL-XML, evitando
possíveis erros na fase de processamento. Em caso de sucesso nesta validação, o CPL
enviado via HTTP é armazenado no servidor estendido que passa então a associar o
processamento deste script às chamadas ao usuário deste serviço.
O servidor gatekeeper H.323 modificado com a extensão CPL, para a
composição final do framework, foi desenvolvido em C++ usando o projeto open source
opengatekeeper [10] e a biblioteca de manipulação XML Xerces, do projeto apache
[30]. Foi realizado um estudo das atuais recomendações de extensão do CPL para o
14
ambiente H.323 descritos pela IETF [20] e ITU-T [27] comparando suas abordagens
como subsídio para a tomada de decisões do projeto. Este servidor suporta as principais
tags do CPL como: Incoming, Address-Switch, Address, Otherwise, Location, Redirect e
Reject e o seu mapeamento no H.323.
1.9 – Programação de Serviços usando Parlay/DFC
Paralelamente as abordagens de reprogramação dinâmica do servidor descritas
em [19], a indústria de telecomunicações vem sofisticando suas plataformas de software
e também perseguindo o objetivo de construir serviços de telefonia (IP e PSTN)
totalmente genéricos [28] devido a grande quantidade de diferentes plataformas de rede
presente nas operadoras telefônicas. Estão sendo construídos, com o intuito de colocar
as diversas plataformas num mesmo patamar gerencial, diversos frameworks de serviço
sob os quais é definida uma rede virtual de telecomunicações, que abrange a comutação
de pacotes, seguindo pelas tecnologias de rede sem fio, e atingindo a própria rede
convencional de telefonia (PSTN).
Esta abstração de rede de telefonia usada pelas operadoras favorecem a criação
de novos serviços que transcendem as arquiteturas instaladas. Nesta área de
programação de serviços e roteamento de chamadas, usando este conceito de rede
virtual de telecomunicações, as tendências mais importantes estão contidas nos
trabalhos do Parlay Group [29] e na implementação Eclipse da AT&T, uma extensão da
arquitetura Distributed Feature Composition (DFC) proposta por [30].
O Parlay Group definiu, a Parlay API como o framework aberto de programação
de serviços de rede, onde tanto parceiros (empresas fora do domínio da operadora da
rede) quanto a própria operadora de rede podem construir novas aplicações
convergentes, sem precisar conhecer profundamente os detalhes da tecnologia usada
pelos elementos da rede. Logo, estes elementos poderiam estar usando SIP, H.323,
MGCP ou ISDN, e todas estas tecnologias estariam sendo controladas
transparentemente pela implementação Parlay. A Sun Microsystems, participante do
Parlay Group, interessada neste nicho de desenvolvimento para telecomunicações está
desenvolvendo sua versão da Parlay API em java, chamada de JAIN (Java API
Integrated Network) [31].
15
A outra proposta para a próxima geração de frameworks de programação de
serviço está sendo desenvolvida pela AT&T Labs com o nome de Eclipse. Ela também
usa uma forma rápida de desenvolvimento de serviços genéricos de telecomunicações,
pela composição de componentes de software distribuídos, usando a técnica chamada de
Distributed Feature Composition (DFC) [28] [30]. No DFC, os serviços abstratos sob a
rede virtual são montados com a composição dos chamados feature boxes ou boxlets,
que são componentes de pilhas de protocolos que permitem rotear a chamada e executar
funcionalidades adicionais.
1.10 – Comparação entre Programação de Serviço usando Parlay/DFC e Ambiente Heterogêneo
A programação de serviços entre Parlay/DFC e nossa abordagem do ambiente
heterogêneo usando CPL tem algumas diferenças importantes. As Parlay e DFC são
formas de programação de serviços de telefonia voltadas para a operadora, sendo esta
responsável pela concepção e implementação dos mesmos, oferecendo posteriormente
aos usuários um leque de serviços a serem adquiridos. A abordagem CPL no ambiente
heterogêneo é mais voltada para o usuário, sendo que este pode definir como será a
reprogramação do servidor de forma livre porém limitada.
As Fig. 1 e 2 ilustram esta comparação.
TelefoneOutro Usuário
TelefoneNovo Cliente
LineInterf.
LineInterf.
CallWait.
0800
InstantMess.Agent
CallTransfer
LineInterf.
AOLInstantMess.
TelefoneVendedor
Computadorcom AOL IM
Agente deVendas
Fig. 1 – Um exemplo do funcionamento da rede virtual Eclipse
A Fig. 1 mostra uma interação envolvendo 3 três pessoas (Novo Cliente, Agente
de Vendas e Outro Usuário) e alguns tipos de componentes (feature boxes) do sistema
Eclipse/DFC. Estes componentes incluem interfaces de linha telefonica (Line Interface),
16
um tradutor de números 0800 (0800), um componente de transferência de chamada
(Call Transfer), um serviço de chamada em espera (Call Waiting), e componentes de
mensagem instantânea (Instant Mess. Agent/AOL IM). O cenário ilustra o resultado de
diversas ações sendo executadas em seqüência. Um Novo Cliente disca para um número
0800; sua ligação é traduzida para o endereço de um Agente de Vendas sendo em
seguida aplicada a transferência da chamada para este. Naquele momento, entretanto, o
Agente de Vendas estava envolvido em conversação com Outro Usuário. O componente
de chamada em espera, agregado a esta comunicação, intercepta o pedido de chamada e
prossegue para o telefone do Agente de Vendas. Este pedido será interceptado pelo
componente de mensagem instantânea instalado, que, ao invés de gerar um tom de
áudio para o telefone do agente, envia uma mensagem instantânea contendo o número
de telefone do Novo Cliente ao programa AOL IM1 do computador do Agente de
Vendas [30].
Agora temos a mesma interação envolvendo gateways, sinalização básica e
scripts CPL no ambiente heterogêneo (Fig 2).
GatewayPSTN/H.323
GatewayPSTN/SIP
Gatekeeper+ CPL
Servidor SIPProxy + CPL
GatewaySIP/H.323
GatewaySIP/InstantMessage
Computadorcom ICQ IM
TelefoneOutro
Usuário
TelefneNovo
Cliente
TelefoneVendedor
H.225 RASSETUP LRQSETUP
Agente deVendas
INVITE
SIPMESG
MESG
Fluxo RTPFluxo RTP
Fig. 2 – Interação de Serviços sob o Ponto de vista do Ambiente Heterogêneo
No ambiente heterogêneo, temos vários gateways que fazem a interface entre as
redes: telefonia convencional (PSTN), SIP, H.323 e Instant Messaging ICQ1, através da
tradução e adequação das mensagens mais básicas entre estes ambientes.
1 AOL IM e ICQ são programas de envio e recepção de mensagens instantâneas na Internet.
17
O Novo Cliente disca para um número 0800 sendo respondido pelo GW
PSTN/H.323. Esta requisição é capturada pelo GK configurado com extensão CPL, que
faze uma busca pelos Agentes de Venda livres e redireciona a ligação para um endereço
SIP. Como o GK não sabe SIP, ele repassa a sinalização para o GW SIP/H.323 que, por
sua vez, sinaliza aquela chamada para a rede SIP. O Agente de Vendas escolhido
também possui um script CPL armazenado no servidor proxy SIP que redireciona as
chamadas para o ICQ, enquanto ele estiver ocupado. É então usado um outro gateway
SIP/Instant Messaging para mandar a mensagem para o ICQ do computador do Agente.
A situação descrita no ambiente heterogêneo mostra que vários scripts CPL
produzem um resultado extremamente interessante, quando estes realizam interações.
No entanto, podem acontecer loops de redirecionamento em certas situações especiais.
Schulzrinne et al [32] conceituam estas interações entre scripts como feature
interaction, ou seja, quando os scripts atuam em certas características que podem
modificar ou influenciar outras características na definição global do comportamento do
sistema. Segundo [33] existem dois tipos de feature interaction: as interações
cooperativas, onde todos os componentes buscam um objetivo comum, mas têm jeitos
diferentes ou não-coordenados de alcançar este objetivo. E as interações adversárias
onde os componentes discordam ou tentam subverter a chamada para seus próprios
benefícios. Algumas soluções para o ambiente CPL são propostas por estes autores,
como um esquema de autenticação universal baseado em assinaturas e ferramentas de
verificação distribuídas, mas nenhuma implementação está disponível.
No caso dos frameworks Parlay/DFC, essa característica de feature interaction é
trabalhada centralizadamente usando ferramentas de verificação distribuídas pois a
operadora tem controle de todos os componentes envolvido em uma interação.
18
1.11 – Organização da Dissertação
A dissertação está organizada em 5 capítulos. No Capítulo 2, apresentamos
como foi implementado o cliente SIP, e algumas questões de modelagem do software e
de desempenho, além da estruturação do ambiente SIP no laboratório VOIP. O Capítulo
3 aborda a telefonia baseada em H.323, e descreve os experimentos de
interoperabilidade realizados com a Internet2, bem como a configuração do Gateway
Cisco 2600. Descrevemos a implementação do framework de programação de serviços
CPL para ambiente H.323 no capítulo 4, desde a sua concepção através de um editor
gráfico, até sua instalação e processamento pelo gatekeeper. Encerramos a dissertação
no Capítulo 5, apresentando as conclusões e sugestões de trabalhos futuros.
19
CAPÍTULO 2 IMPLEMENTAÇÃO DE CLIENTE SIP ROBUSTO BASEADO NA
WEB E IMPLANTAÇÃO DO AMBIENTE SIP NO LABORATÓRIO VOIP
Este capítulo descreve a implementação de um serviço Web-to-Dial, tendo como
características importantes a robustez no tratamento de mensagens de sinalização, a
interoperabilidade com a arquitetura SIP e a qualidade da captura, recepção e
transmissão da mídia. Posteriormente, veremos a inserção deste serviço no contexto SIP
implantado no laboratório de VOIP. O capítulo está organizado em seis seções. Na
Seção 2.1, descrevemos detalhes da implementação deste serviço pelo uso de Java
Applets e as questões de segurança envolvidas. Na seção 2.2, detalhamos os módulos
que compõem o software, e os paradigmas de programação utilizados. A discussão
sobre a robustez do segmentador de protocolo SIP é apresentada na Seção 2.3. Na Seção
2.4, discutimos sobre formas de captura de mídia pelo browser. Os testes de
conformidade SIP são descritos na seção 2.5, e ao final do capítulo na Seção 2.6,
mostramos uma arquitetura SIP montada no laboratório VOIP que permite a um usuário
navegando na Internet realizar ligações a ramais telefônicos da UFRJ.
2.1 – Opção pelo Uso do Java Plugin
Para embutir o software de telefonia IP numa página Web, utilizamos a
tecnologia de Java Applets sob o ambiente de execução Java-Plugin [34]. A vantagem
do Java-Plugin é que sua instalação é simples, transparente, e feita sob demanda,
quando o usuário acessa a página contendo o serviço. Além disso, ela permite usar no
browser todas as novas bibliotecas do Java. A outra possível opção seria o uso da
própria máquina virtual Java (JVM) embutida nos browsers, mas esta não permitiria
20
trabalhar com bibliotecas de programação Java 2 (como a Swing), presentes nas novas
versões do Java Runtime Environment, limitando certas funcionalidades.
Quando a applet é executada, ela automaticamente entra no ambiente de
execução Java-Plugin ao invés de ativar a máquina virtual padrão embutida no browser.
Para que isso aconteça é necessário inserir algum código HTML especial naquela
página Web. Para gerar este código HTML especial usamos a ferramenta de conversão
Java Plugin Converter distribuída com o kit de desenvolvimento Java.
O uso da tecnologia Java Applets tem muitas implicações nos níveis de
segurança do software embutido na página e que executa em cooperação com os
browsers.
Realizar uma chamada telefônica partindo-se da Web para qualquer outro IP
requer que a applet tenha permissões especiais dadas pelo browser. O modelo de
segurança ut ilizado pelo Java-Plugin faz restrições ao desenvolvimento de programas
que precisam acessar os recursos de I/O e de rede, além de limitar o uso amplo de
threads nas applets.
Para que o serviço Web-to-Dial pudesse ultrapassar estas restrições,
principalmente permitindo enviar datagramas UDP para outros servidores da rede,
optamos pelo uso de certificados eletrônicos auto-gerados [35], como forma de assinar o
código da Java Applet e, desta forma, ter completa liberdade para acessar os recursos
locais. A opção do uso, pela applet, de objetos de segurança da JVM embutidos nos
browsers, em oposição ao uso dos certificados, tornaria a programação totalmente
dependente do browser, o que não é adequado ao nosso ambiente. Por outro lado, o uso
de certificados auto-gerados é a forma usada por desenvolvedores para evitar o custo de
obtenção de um certificado eletrônico das empresas Verisign® ou Thawte®
(certificadoras oficiais), nas fases iniciais de um projeto.
2.1.1 – Trabalhando com Applets Assinadas para acessar Serviços Remotos de Rede
21
Fig. 3 – Decisão sobre liberar os recursos usando Certificado Auto-
Gerado
Uma vez que o código Java desenvolvido foi incorporado a um arquivo
contendo o conjunto de objetos (JAR – Java Archive) e devidamente assinado (usando
as ferramentas keytool e jarsigner do kit de desenvolvimento java). Seu uso dentro de
uma página HTML convertida para usar marcadores HTML (tags) de Java Plugin faz
com que o browser apresente uma caixa de diálogo sobre a assinatura deste código (Fig.
3). O usuário deve escolher a opção “Grant this session”, que liberará a applet de todas
as restrições. Um cuidado especial que deve ser tomado no uso de certificados é
verificar a ausência no arquivo de políticas de segurança do JRE (Java Runtime
Environment) da entrada: permission java.lang.RuntimePermisssion “usePolicy”. Se
ela existir, os certificados não terão efeito de liberação algum. Como o Java-Plugin é
uma tecnologia independente de browser, não é necessário prover certificados diferentes
para cada browser, para assinar o código.
2.2 – Detalhamento dos Módulos do Cliente SIP usando Applet
O serviço Web-to-Dial é na verdade um telefone IP SIP básico embutido no site.
Seguindo a classificação de cliente básico SIP [36], nossa implementação em applet
(Fig. 4) suporta a lista de funções abaixo:
22
1- Envia/recebe INVITE sobre UDP;
2- Gera resposta de Acknoledgement (ACK) apropriadamente;
3- Dá opção ao usuário de aceitar e rejeitar chamadas telefônica IP;
4- Monta cabeçalho SDP (RFC 2327) contendo pelo menos um codificador de mídia;
5- Trata apropriadamente os cabeçalhos To/ From/ Call-ID/ Cseq/ Via/ Content-
Length/ Content-Type;
6- Realiza a geração do complemento tag= contendo o descritor da chamada no
cabeçalho To;
7- Envia e recebe mensagem básica de terminação de chamada BYE via UDP;
8- Permite o uso da forma compactada dos cabeçalhos SIP;
9- Rejeita métodos desconhecidos com respostas 501 (Not Implemented);
10- Envia e recebe mídia de áudio via RTP, possivelmente sem o uso de RTCP.
Podemos dividir nossa implementação em 6 módulos básicos: Módulo de
Conexão ou Transporte da Sinalização, Módulo Gerador de Mensagens SIP, Módulo
Segmentador de Mensagens SIP, Módulo de Transmissão e Recepção de Mídia via
RTP, Módulo Gerenciador da Máquina de Estados SIP e Módulo de Interface com o
Usuário.
Fig. 4 – Implementação UFRJ SIP Client
23
Fig. 5 – Diagrama de Classes do Módulo de Transporte da
Sinalização SIP
Na implementação dos módulos houve uma preocupação constante em utilizar
as melhores práticas na programação Java. Assim, na programação do módulo de
transporte de sinalização SIP, o uso da interface Connection (Fig. 5) faz com que a
sinalização possa ser feita transparentemente tanto sobre UDP quanto TCP. Neste
módulo, temos a thread compartilhada ConnectionServerHandler fazendo o papel de
recepção de mensagens enquanto a classe ConnectionHandler transmite as mensagens.
Os métodos On( ) e Off ( ) de gerenciamento da conexão são usados para evitar a
transmissão e recepção simultânea pela Connection, operando como semáforos no
acesso concorrente. Uma possível extensão deste modelo para o gerenciamento de mais
de uma chamada, interessante do ponto de vista de um servidor SIP, seria a criação de
um pool de Connections. É relevante comentar que a estrutura de dados em Java usada
para receber tanto datagramas UDP, quanto o fluxo de dados no TCP, que são lidos e
armazenados de maneira diferente, foi a classe BufferedReader.
Os módulos de geração e segmentação de mensagens foram implementados com
codificação distinta. Para a geração foi usado um codificador de mensagens rápido
baseado em vetor, contendo todos os cabeçalhos SIP em posições fixas. Com esse vetor
é possível montar eficientemente a mensagem SIP e também fazer uso de compactação
de cabeçalhos (Fig. 6). Mas na segmentação (parsing) das mensagens, preferimos usar a
biblioteca desenvolvida pelo NIST [37], parte da implementação oficial do módulo SIP-
JAIN. Esta biblioteca propicia uma forma mais robusta e flexível de tratamento de
24
mensagens SIP, pois está baseada na gramática ABNF do SIP (veja Seção 2.3), e opera
corretamente frente a cabeçalhos alterados e/ou inexistentes.
Fig. 6 – Diagrama de Classes do Módulo de Geração de Mensagens SIP
O módulo de transmissão e recepção de Mídia via RTP/UDP usa a biblioteca de
manipulação de mídia Java Media Framework versão 2.1.1 da Sun Microsystems. Esta
biblioteca tem uma ampla variedade de codificadores/decodificadores de mídia (como o
G.711, GSM e MPEG Layer III Audio), permite captura de áudio a partir de um applet,
possibilita configurar os buffers de compensação de jitter e realizar a apresentação de
mídias gravadas (como o som de alerta do telefone IP). A biblioteca ainda oferece a
possibilidade de adicionar um componente de exibição gráfica, que permite visualizar
estatísticas encaminhadas pelos pacotes RTCP. Estas estatísticas contém relatórios
periódicos RTCP sobre: variação do atraso (jitter), número de pacotes recebidos,
número de pacotes perdidos, número de pacotes perdidos por atraso, entre outros.
Um possível módulo estatístico baseado nas informações RTCP obtidas pelo
JMF ainda não foi finalizado, mas pretendemos completá- lo e seguir os padrões de RTP
MIB para armazenar as estatísticas obtidas assim, como é feito na ferramenta de
monitoramento descrita por [38]. Um ambiente de gerência poderia ser implementado
25
usando um applet remoto que recolheria as estatísticas localmente da máquina do
cliente, as quais seriam, posteriormente, enviadas ao servidor onde reside o applet, de
modo a termos um panorama da qualidade das ligações que os usuários estão
experimentando.
Fig. 7 – Gerenciamento da Máquina de Estados SIP
O módulo gerenciador da máquina de estados SIP (Fig.7) recebe, das classes de
transporte e da interface gráfica, eventos que disparam os métodos ProcessRequest e
ProcessResponse, sem conhecimento sobre qual máquina de estados estará atuando
sobre estes métodos. Usamos o padrão de projeto Command [39] para encapsular esta
requisição e o padrão de projeto Mediator [39] para mediar a comunicação entre a
interface gráfica, o gerenciador de máquina de estados e o módulo de transporte da
sinalização. Internamente aos objetos gerenciadores FSMUA (Finite State Machine
User Agent), temos uma máquina de estados finita representando as transações de
estado do SIP. Nos casos do InviteFSMUA e RegisterFSMUA, por exemplo, cobrimos
todos os possíveis estados da seção INVITE Client Transaction e REGISTER
Transaction do padrão SIP [3].
Por fim, o módulo da interface com o usuário (vide Fig. 4) tem mais 4 painéis
integrados, cada um com seus próprios conjuntos de botões, campos de formulário e
opções. São eles: New Call (Nova Chamada), Register (Registro), Configuration
(Configurações do Usuário) e Statistics (Estatísticas). A captura dos eventos de click de
botões e preenchimento de campos são feitos pelo uso de interfaces Listeners. Isto é
automatizado no construtor de interface gráfica da ferramenta JBuilder da Inprise, que
foi usada no desenvolvimento deste projeto.
26
Dentre os módulos implementados, alguns, como o segmentador de mensagens
(parser) e o de transmissão e recepção de mídia, têm um impacto grande sobre o atraso
total da comunicação. Por isso, nas próximas seções, analisaremos questões de
performance relacionadas com estes módulos.
2.3 – Segmentador de Mensagens Gerado pela Gramática SIP ABNF
O SIP, assim como muitas especificações técnicas da IETF, usa uma versão
modificada da notação BNF (Backus-Naur Form) chamada ABNF (Augmented BNF)
[40] para formalizar matematicamente seus protocolos. Esta notação, similar à EBNF
(Extended BNF), tem como objetivo descrever sem ambigüidade a sintaxe de uma
linguagem. Ela é usada para definir uma gramática do protocolo, e possibilitar a
construção mecânica de ferramentas de segmentação (parsing) específicas para este
protocolo.
A biblioteca NIST-SIP foi montada sob uma estrutura de compilador de
compiladores (semelhante ao YACC – Yet Another Compiler Compiler, popular gerador
de parser em C++ para Unix). A base para a construção do segmentador (parser) SIP
desta biblioteca é oriunda do projeto ANTLR [41], que possibilita a construção de
parsers, tree-parser, e lexers, suportados por gramáticas EBNF do tipo por redução top-
down LL (a maneira mais fácil de fazer segmentação segundo [42]). Isso torna o
processo de segmentação bastante robusto, embora com acréscimo no custo
computacional. Para os propósitos do JAIN, que é o desenvolvimento de aplicações por
terceiros para redes de operadoras, para o qual a NIST-SIP foi construída, era preciso
realmente garantir esta robustez superior.
Este processo de segmentação é realizado logo após a recepção da mensagem
SIP pela thread ConnectionServerHandler. Segmentamos a primeira linha do buffer de
recepção e usando um bloco lógico conseguimos diferenciar se esta mensagem é de
requisição ou de status. Para depois dentro do gerenciador da máquina de estados
apropriado fazer a segmentação do resto da mensagem (Quadro 1).
27
laststatus = parser.parseSIPStatusLine(firstline); if(laststatus!=null) { System.out.println("Status Code = " + laststatus.getStatusCode( )); } else { lastrequest = parser.parseSIPRequestLine(firstline); if(lastrequest!=null) { System.out.println("Method = " + lastrequest.getMethod( ));
} Quadro 1 – Diferenciação da mensagem SIP através do Parsing da primeira linha
Quando iniciamos o desenvolvimento do cliente SIP, a biblioteca NIST-SIP
realizava apenas a segmentação das mensagens, não suportando a sua geração, que teve
que ser feita em codificação própria. Em 2001, o projeto NIST-SIP também
disponibilizou sua versão do montador de mensagens SIP a partir de seus objetos
(SIPHeaders e SIPMessage). Constatamos, no entanto, que o atraso das mensagens
geradas no início da chamada pelo NIST-SIP era bem superior ao observado no
esquema simplicado que havíamos desenvolvido. Os tempos medidos estão mostrados
na Tabela 1.
Tipo de Mensagem SIP
Algoritmo de Construção de Mensagem usando Ve tor e preenchendo os seus índices com as Strings das linhas de cabeçalho (UFRJ)
Algoritmo de Construção de Mensagem usando criação de objetos SIPHeader e posterior codificação de todos os headers em sua forma canônica (NIST-SIP)
INVITE inicial 300 iterações : tempo de 548,04 ms 300 iterações : tempo de 1443,29 ms ACK após o recebimento de 200 OK
300 iterações : tempo de 670,03 ms 300 iterações : tempo de 661 ms
Tabela 1 – Resultados do Uso do Montador de Mensagens NIST-SIP em comparação com o montador de mensagens simplificado da implementação SIP Applet (AMD K7/256 MB
RAM/média de 30 experimentos)
Na tabela acima, a diferença maior observada entre desempenhos na montagem
da mensagem INVITE inicial pode ser explicada pela maneira com que os algoritmos
trabalham. No nosso módulo gerador de mensagens, preenchemos os cabeçalhos SIP em
um vetor de tamanho fixo (Fig. 6), cada cabeçalho tendo uma posição única no vetor.
Obtivemos o tempo de 548,04 ms em 300 iterações de geração (usamos 300 iterações
para ressaltar a diferença, que é pequena no nível de uma mensagem, mas pode se tornar
um problema se utilizarmos este montador em um servidor SIP). No algoritmo usado
pelo NIST-SIP, por outro lado, o tempo em 300 iterações foi de 1443,29 ms, pois é
preciso criar primeiro os objetos que formam cada cabeçalho preenchendo-os
apropriadamente. Depois, juntar estes cabeçalhos para formar o objeto da mensagem
28
SIP, que é então codificada para sua forma canônica (em texto), passando por muitos
processos de criação de objetos.
Comparando esta quantidade de objetos criados com nossa implementação
percebe-se a diferença, pois ela cria somente um objeto vetor. Podemos concluir que
com o uso de vetor fixo, ganha-se em velocidade, mas perde-se em robustez e validação
de texto. Embora, isto possa ser feito pela própria interface gráfica.
Na tabela 1, a vantagem na construção da mensagem SIP usando nossa
abordagem, ocorre somente quando estamos trabalhando com mensagens iniciais. No
caso do processamento de uma mensagem intermediária (ACK após o recebimento do
200 OK), a construção da mensagem de resposta fica bastante facilitada, pois os objetos
dos cabeçalhos do NIST-SIP (SIPHeaders) já foram construídos pelo próprio processo
de segmentação, estando prontos e configurados. A opção de copiar estes objetos e
incorporá- los à nova mensagem SIP (NIST-SIP) é bem mais eficiente do que extrair
campo por campo em formato texto, validar e preencher um novo vetor com a
mensagem SIP. Nos testes, o NIST-SIP levou cerca de 661 ms para montar uma
mensagem ACK (em 300 iterações), enquanto que nosso algoritmo, contando o tempo
de extração dos textos dos cabeçalhos do NIST-SIP e testes de validação, levou 670,03
ms. A reutilização dos cabeçalhos SIP nas mensagens intermediárias ocorre
constantemente, durante toda a transação da chamada telefônica IP, outro ponto
favoráverl pelo uso do NIST-SIP. O trecho de código abaixo (Quadro 2) mostra a
construção da mensagem ACK utilizando o objeto newmsg que contém uma mensagem
segmentada (200 OK).
SIPMessage sipm = null; sipm = new SIPRequest(); RequestLine rqline = new RequestLine(); rqline.setMethod("ACK"); rqline.setSipVersion("SIP/2.0"); sipm.attachHeader(rqline,true); sipm.attachHeader((Subject) newmsg.getSubjectHeader( ), true); sipm.attachHeader((Via) newmsg.getViaHeaders().getFirst(), true); sipm.attachHeader((Cseq) newmsg.getCSeqHeader().getSeqno(), true); sipm.attachHeader((From) newmsg.getFromHeader(), true); sipm.attachHeader((CallID) newmsg.getCallIdHeader( ), true); sipm.attachHeader((To) newmsg.getTo Header(), true); StringBuffer stringb = new StringBuffer(sipm.encode());
Quadro 2 – Trecho do Código da Montagem da mensagem ACK com NIST-SIP
29
Como as duas formas tem suas vantagens e desvantagens, optamos por usar
nosso montador apenas para mensagens iniciais (INVITE, REGISTER), e usar o
montador do NIST-SIP para mensagens que são intermediárias ao estabelecimento da
chamada (200 OK, ACK, BYE). Recentemente, a nova versão da biblioteca do NIST-
SIP adotou um esquema mais rápido de codificação de mensagens iniciais que diminui
o número de objetos criados. Ela usa o padrão de projeto Factory [39] para criar, de
uma só vez a mensagem SIP preenchendo-a com alguns cabeçalhos padronizados, ao
invés do método anterior de configuração de todos os subcampos de cada cabeçalho.
O método de construção por Factory simplifica bastante a construção de
cabeçalhos nas mensagens SIP iniciais, se concluirmos que o tempo de construção das
mensagens iniciais desta abordagem também for pequeno, pode valer a pena investir na
remodelagem do montador.
2.4 – Captura de Mídia pelo Browser
Outro ponto crítico na implementação do cliente SIP foi resolver a questão de
como capturar som a partir de um applet. A Sun Microsystems, mantenedora do Java,
trabalha atualmente com duas APIs de manipulação de som: Java Sound e JMF. Estas
duas bibliotecas têm soluções para a captura de áudio na Internet. Além da performance
da biblioteca, a questão da segurança também foi um fator que influenciou nossa
decisão.
A API JMF na sua versão 2.1.1a [43] provê ferramentas próprias para a
configuração das permissões de segurança para a gravação de áudio pela Internet sem
precisar trabalhar com certificados eletrônicos de terceiros. No caso da Java Sound,
incorporada ao kit de desenvolvimento Java versão 1.2+, seria possível a captura de
áudio pelo uso de outros certificados eletrônicos. Entretanto, ela não tem qualquer
mecanismo para transmissão RTP, nem possibilita a conversão de codificadores/
decodificadores de áudio com a mesma facilidade que a JMF. Existe uma tendência de
que em breve a Java Sound e a JMF se tornem uma só biblioteca. Para ilustrar esta
tendência podemos mencionar que atualmente temos métodos nas duas bibliotecas de
classes com mesmo nome, e que podem causar conflitos.
30
Outras diferenças entre a JMF e a Java Sound recaem na velocidade e nos tipos
da captura suportados. Como a Java Sound (javax.sound) é uma biblioteca incorporada
ao JRE, foi desenvolvido um esquema via máquina virtual para possibilitar a captura de
áudio. Já a JMF usa rotinas de código nativo em C++ (para Linux, Windows e Solaris)
para realizar esta captura diretamente do hardware, seja de áudio, de vídeo, ou outros
dispositivos, passando por cima do processamento da máquina virtual, aumentando a
sua performance. Posteriormente, o JMF trabalha com os dados capturados,
encapsulando em uma interface JNI (Java Native Interface), e preparando este fluxo de
mídia para ser transmitido via RTP/UDP.
Nosso módulo RTP, transmissor e receptor de áudio, é baseado na JMF (Fig. 8).
A classe AudioBox é quem dispara a execução dos objetos AudioTransmit e
AudioReceive simultâneamente, assim que na máquina de estados atingirmos o estado
de chamada estabelecida. Isso acontece logo após a fase de negociação de mídias SIP
(envio de ACK e recebimento de 200 OK), onde os parâmetros da mídia passados pelos
cabeçalhos SDP Connection (c) e Media (m) negociados, contemplam endereço IP,
porta UDP e tipo de mídia que estará sendo transmitida e recebida.
Fig. 8 – Classes de Transmissão e
Recepção de Áudio
Atualmente, estamos suportando apenas áudio, mas as classes foram projetadas
para receber vídeo. A classe AudioReceive também provê a capacidade de detectar, ao
nível de fluxo RTP, mudanças no formato de codificação pela parte remota. Por
2.4.1 – Detalhamento do Módulo de Transmissão e Recepção de Áudio RTP
31
exemplo, se o outro cliente baseado em estatísticas RTCP resolver trocar o codificador
de mídia para preservar a qualidade da transmissão, a applet detectará esta mudança no
Payload Type RTP, e iniciará um processo de re-INVITE, onde ocorrerá nova
negociação das capacidades, sem que o estado da chamada seja alterado.
O trecho do código abaixo (Quadro 3), explica o procedimento orientado a
objetos de transmissão RTP usado JMF (extraímos as capturas de erros para facilitar o
entendimento).
1 dataOutput = Manager.createDataSource(new MediaLocator("dsound://44100")); 2 processor = Manager.createProcessor(dataOutput); 3 boolean result = waitForState(processor, Processor.Configured); 4 TrackControl [] tracks = processor.getTrackControls(); 5 ContentDescriptor cd = new ContentDescriptor(ContentDescriptor.RAW_RTP); 6 tracks[5].setFormat(AudioFormat("ULAW/rtp", 8000, 8, 0); 7 result = waitForState(processor, Controller.Realized); 8 dataOutput = processor.getDataOutput(); 9 sendStream = rtpManager.createSendStream( dataOutput, 0); 10 sendStream.start(); 11 processor.start();
Quadro 3 – Trecho do Código em Java da Sequencia de Captura de Áudio e Transmissão via RTP
O objeto dataOutput (1) é a fonte de captura dos dados, estamos usando o
capturador de áudio DirectSound da Microsoft (dsound) para otimizar a velocidade de
captura, com parâmetro de amostragem de 44 khz. É preciso criar um objeto Processor
(2), abstração de um processador de mídia, pois logo em seguida vamos transformar a
amostragem capturada na codificação apropriada (4, 5, 6). As chamadas do método
waitForState (3,7) são bloqueantes e esperam por eventos vinculados a preparação do
objeto processor (Configured, Realized). Durante este tempo de preparação, são
alocadas as regiões de memória que farão parte do processamento da mídia. Estes
bloqueios também servem para executar certos métodos que só funcionam durante o
intervalo de preparação, por exemplo, esperando certas pré-condições do processor
serem atingidas. O processor então é vinculado a fonte de captura, o dataOutput (8), de
modo que a mídia capturada seja processada e transformada em um fluxo RAW_RTP
de áudio “ULAW”, com taxa de 64kbps. O objeto rtpManager instanciado em um passo
anterior a este algoritmo, cria o objeto SendStream, abstração do buffer de envio RTP
(9), e então são ativados os objetos sendStream e processor para que a captura se
transforme em pacotes RTP e seja transmitida ao ponto final (10, 11).
32
Nossa opção de desenvolvimento conforme visto na seção anterior é pelo uso do
JMF no módulo de transmissão e recepção de áudio. O JMF tem várias vantagens,
como maior facilidade de manipulação da mídia (configuração de buffers de
compensação de jitter, buffers de playout, codificadores, multiplexação de mídia) e de
manipulação do RTP (captura de eventos como a detecção de mudança de payload e
parâmetros RTCP). Entretanto, esta decisão tem uma importante desvantagem: os
engenheiros da Sun não desenvolveram ainda um instalador silencioso e por demanda
para o JMF. Ou seja, segundo a recomendação deles é necessário realizar o download e
instalar diretamente o JMF com código nativo (chamado de performance pack) na
máquina local do cliente. A partir daí, o usuário pode habilitar, através do aplicativo
JMFRegistry (ferramenta do pacote JMF), a opção de captura de áudio pelas applets,
conforme Fig. 9.
Fig. 9 – Utilização do JMF Registry para habilitar
captura de áudio pela Applet
Em agosto de 2001, a Sun disponibilizou o código fonte da biblioteca JMF e
suas aplicações, incluindo o JMFRegistry. Realizamos uma análise sobre o processo de
captura via applet, e verificamos que existe uma dependência muito grande das classes
dos performance pack JMF com os códigos nativos de cada plataforma (Linux, Solaris e
Windows). Seria portanto necessário copiar este código nativo correspondente, por
demanda, para a máquina do cliente. A opção usada no projeto até agora é a instalação
direta do pacote performance pack JMF.
2.4.2 – Questões de Desempenho do Pacote JMF Performance Pack
33
Realizamos algumas medidas para identificar pontos de gargalo no nosso código
como o tempo de preparação dos objetos da JMF no início da transmissão e da recepção
de áudio. Os parâmetros básicos destes testes foram o uso do capturador de mídia
DirectAudio (“dsound” ao invés de “javasound”), com taxa de amostragem 44100Hz,
montando um fluxo RTP/? law de 8000 Hz (taxa de bits de 64 kbps), em um
computador AMD K-7 com 256 MB RAM.
Na classe AudioTransmit observamos que houve um atraso da ordem de alguns
segundos entre o tempo de recebimento do 200 OK do estabelecimento de chamada e o
início da transmissão de áudio. Este atraso é muito variável (de 3 segs a 15 segs)
dependendo de fatores como velocidade do processador, quantidade de memória e
tempo na resolução de nomes (DNS) utilizado pelo método addTarget da classe
RTPManager. Este último é usado para resolver o parâmetro RTCP Canonical Name
(CNAME) que descreve os participantes de uma sessão multimídia. Entre estes tempos,
o que mais contribui para o atraso do início da transmissão é o bloqueio no estado
Realizing/Realized do objeto processor, onde é preparada para transmissão a mídia
capturada e convertida para o formato PCM ? law de 8000 Hz.
Por outro lado, na classe AudioReceive, o início da recepção também após o 200
OK, aconteceu mais rápido ficando em torno de 2,6 segundos. Apesar do método
addTarget também estar presente nesta classe (método que contribui para o atraso na
transmissão), ele é acionado após o início da recepção do fluxo RTP, não impactando
diretamente sobre o tempo entre o recebimento do 200 OK e o início da recepção de
áudio.
O fator tempo é extremamente relevante no contexto das telecomunicações. O
tempo de captura, de bufferização e de apresentação da mídia devem ser otimizados.
Temos algumas recomendações para otimizar a manipulação de áudio nas
comunicações usando o java. Primeiramente é crucial usar os objetos DirectAudio,
DirectAudioRenderer que fazem acesso direto ao hardware tanto para captura, quanto
na apresentação da mídia. Em segundo lugar é necessário configurar um tamanho de
buffer de recepção pequeno em torno de 125 ms. Este buffer reduzido diminue
sensívelmente o tempo em que um datagrama RTP/UDP ficará na fila do buffer de
apresentação até ser tocado. Embora, essa dimunição tenha uma desvantagem, a
34
quantidade de pacotes perdidos em conseqüência de jitter (atraso entre pacotes) deve
aumentar por não termos buffer suficiente para compensá- lo.
Outra recomendação importante é que os codificadores de mídia devem ser
escolhidos com cuidado, analisando-se o custo-benefício de sua utilização. Por
exemplo, o codificador MPEG Layer III Audio tem uma qualidade excelente para
música e baixa taxa de transferência, mas para uma conversa online o seu processo de
codificação/decodificação usa muito recurso de processamento, podendo aumentar o
tempo fim-a-fim da comunicação interativa à níveis intoleráveis.
2.5 – Testes de Conformidade entre Implementações SIP
A interoperabilidade de clientes e servidores SIP tem especial importância no
grupo de trabalho SIP da IETF, são realizadas periodicamente conferências somente
para testes entre várias implementações de empresas e universidades [44].
Fizemos uma bateria de testes de conformidade SIP, numa rede local usando
computadores com sistema operacional Windows 2000, entre nosso cliente SIP applet e
vários clientes (Cliente SIP da Universidade Columbia v. 1.6, Cliente SIP da Ubiquity
v. 2.0, Cliente SIP da Hughes v1.0), servidores (Servidor SIP da Universidade
Columbia e Servidor SIP do NIST) e gateway SIP/PSTN (Cisco 2600). O objetivo
destes testes foi mapear problemas de interoperabilidade entre nossa implementação e
os demais softwares, usando a metodologia de testes estabelecida pelo IMTC
(International Multimedia Teleconferencing Consortium) em 2000 [45].
Esta metodologia descreve cenários de compatibilidade entre entidades SIP.
Cada cenário é descrito por: entidades envolvidas, detalhamento da seqüência de testes,
e critérios de avaliação para completar o cenário com sucesso. Segundo a metodologia
do IMTC são cinco os cenários definidos para o SIP.
O primeiro cenário é definido como: comunicação ponto-a-ponto de Áudio sem
nenhum servidor. Nele, dois clientes SIP são colocados em comunicação direta na
mesma rede local. Eles devem seguir o ciclo do estabelecimento de chamada SIP
(INVITE inicial, respondido com sinalização de respostas provisórias como 180
Ringing, negociação final da mídia com 200 OK e o ACK), logo após deve ser avaliada
a qualidade da mídia e a terminação da chamada por um dos clientes. A tabela 2 mostra
os resultados de nossos testes.
35
Cliente SIP Columbia Versão 1.6
Cliente SIP Ubiquity Versão 2.0
Cliente SIP Hughes 1.0
Cliente SIP Applet (Web to Dial)
Funcionou bem nas várias tentativas diferentes. Entretanto apresentou instabilidade principalmente com a transmissão de mídia via RAT e recepção de BYE.
Funcionou bem nas várias tentativas. Tivemos entretanto que resolver um problema, que não deveria acontecer neste cliente, ao ser usado um caracter espaço a mais no cabeçalho origin do SDP.
Funcionou perfeitamente frente a vários testes diferentes.
Tabela 2 – Resultados de cinco observações dos testes no Cenário 1 de Interoperabilidade entre Clientes SIP (Ponto-a-Ponto) (segundo IMTC)
Uma observação a ser feita com relação ao teste acima é que o cliente de
Columbia atualmente está na sua versão 1.7 (versão comercial) e não tínhamos licença
para usá- lo. Portanto alguns dos erros encontrados podem ter sido resolvidos nesta nova
versão.
Nos cenários 2, 3 e 4 que utilizam um servidor SIP como entidade de
interoperação, usamos o Servidor SIP de Columbia 1.17, que armazena os registros em
servidor MySQL, e outro Servidor SIP escrito em java usando a biblioteca NIST-SIP,
que armazena os registros na memória. Ambos os servidores suportam as atividades de
registro (alvo do cenário 2), de redirecionamento (alvo do cenário 3) e de proxy (alvo do
cenário 4) previstos na metodologia do IMTC. Os resultados podem ser vistos na Tabela
3. A seqüência de testes de registro usando o endereço multicast 224.0.1.75 não pôde
ser concluída, pois nosso software não suporta esta característica. O endereço multicast,
neste contexto, serve para que os clientes enviem mensagens REGISTER para qualquer
servidor SIP associado ao endereço multicast, facilitando a busca do mesmo.
Servidor SIP Columbia Versão 1.17
Servidor SIP NIST
Cliente SIP Applet (Web to Dial)
Funcionou bem para o cenário local.
Funcionou perfeitamente com a applet, entretanto em testes complementares feitos com o cliente SIP Columbia, o cabeçalho Contact não pode ser segmentado pelo NIST-SIP.
Tabela 3 – Resultados de cinco observações dos testes nos Cenários 2, 3, 4 de Interoperabilidade entre Cliente SIP e Servidor SIP (segundo IMTC)
O último teste de interoperabilidade, o cenário 5, descreve a seqüência de
ligação entre o telefone IP e um telefone convencional. Utilizamos um roteador Cisco
2600 para realizar este teste. O applet realizou a sinalização, e a transmissão de mídia
com sucesso, entretanto houveram alguns problemas na recepção de mídia vinda do
Cisco 2600 (veremos este problema na próxima seção).
36
Outro erro detectado e que compromete a interoperabilidade é que o Cisco 2600
não está enviando mensagem BYE ao final da chamada, como recomendado pelo
padrão SIP, quando desligamos o telefone na rede telefônica convencional. Logo
algumas implementações de clientes não souberam tratar este comportamento. Para isso,
é necessário detectar que o fluxo de mídia RTP vindo do Cisco foi finalizado, e gerar
automaticamente uma mensagem de BYE para o Cisco 2600.
Nos testes de interoperação entre a implementação do SIP Applet e o gateway
SIP/PSTN (Cisco 2600), detectamos uma falha de projeto da API Java Media
Framework. O problema consiste no seguinte: após termos iniciado uma sessão SIP,
com a sinalização acontecendo perfeit amente entre a applet e o gateway SIP, iniciamos
a abertura dos canais de mídia. No caso da transmissão, ela acontece perfeitamente. No
entanto na recepção funciona por apenas alguns segundos, e depois pára de funcionar.
Para capturar este erro implementamos (Quadro 4) em nossa classe de recepção
uma interface ReceiveStreamListener, com ela podemos implementar métodos como o
update (callback) sendo acionado toda vez que acontecer algum evento relacionado a
recepção de fluxos RTP. O RTPManager é configurado para receber estes eventos
através de rtpManager.addReceiveStreamListener(this). Dentro da classe AudioReceive
implementamos o método update para capturar a mudança do codificador RTP:
/** Implementação do Método update da Interface ReceiveStreamListener */ public synchronized void update( ReceiveStreamEvent evt) { RTPManager mgr = (RTPManager)evt.getSource(); Participant participant = evt.getParticipant(); ReceiveStream stream = evt.getReceiveStream(); if (evt instanceof RemotePayloadChangeEvent) { // MUDANÇA DE PAYLOAD TYPE System.out.println("\n - Received an RTP PayloadChangeEvent."); System.out.println("\n - + ((RemotePayloadChangeEvent) evt).getNewPayload( )"); }
Quadro 4 – Callback da Classe AudioReceive do SIPApplet para capturar mudança de payload
Em testes com o Cisco 2600 fomos surpreendidos no fluxo de recepção de mídia
vindo deste gateway, pela mudança constante no campo do protocolo RTP Payload
Type no tempo. Os valores recebidos a cada intervalo de microsegundos são: ora o
Payload 0 (segundo a especificação RTP, payload do codificador PCM ?LAW)
2.5.1 – Problema da Interoperabilidade dos Fluxos de Mídia entre Gateway SIP/PSTN (Cisco 2600) e Java Media Framework (JMF)
37
negociado por nosso applet na sinalização SIP, ora o payload type 19 (sem mapeamento
no JMF) que pode ser denominado ruído de conforto (CN) enviado pelo Cisco 2600.
O ruído de conforto é usado na telefonia para dar aos usuários a sensação de que
mesmo que ninguém esteja falando em certo momento, ainda estamos com a chamada
ativa na rede de telefonia, através de um ruído quase imperceptível enviado aos nossos
ouvidos. Segundo a ITU-T [46], as implementações dos codificadores G.711 (PCM)
deveriam usar Comfort Noise (CN). A IETF está mapeando esta especificação em [47],
mas com o valor do Payload Type (PT) em 13 ao invés de 19. Neste padrão o ruído de
conforto consiste de um único octeto contendo o nível de ruído desejado ou a
informação espectral dos octetos subsequentes.
A documentação da biblioteca JMF da Sun diz que mudanças do cabeçalho
payload type no meio de um fluxo devem ser manipuladas com a criação de um novo
player para manipular este novo formato. Mas o ruído de conforto agregado ao fluxo
principal é um caso especial, que a JMF não suporta. Em mensagens da lista de
discussão JMF-INTEREST datadas de janeiro de 2001 é proposta uma maneira
temporária de consertar o problema.
A resolução consiste em registrar um novo formato de Payload 19 no
gerenciador de RTP. E escrever um pré-processador para este formato, permitindo uma
manipulação direta no comportamento deste codificador. Como estaríamos trabalhando
internamente com a classe do codificador poderíamos camuflar o PT 19 nesta fase,
descartando os pacotes RTP com o PT 19, e enganando o processador de mídia do JMF
devolvendo a ele, o PT 0, sem que ele consiga capturar a mudança de payload. A idéia,
portanto, é filtrar os dados do ruído de conforto CN que estão agregados ao fluxo PCM
pelo seu descarte. Implementamos estes passos especificados pela Sun, mas a recepção
ainda apresenta erros. Tentamos entrar em contato com engenheiros da Sun que
participam da lista de discussão do JMF, mas não fomos atendidos. Como o PT para CN
é um tema novo nas discussões da IETF, esperamos que as próximas versões do JMF
venham a incorporar estas mudanças.
O stack RTP do RAT (Robust Audio Tool da University College of London)
embutido no cliente de Columbia versão 1.6 e o stack RTP do Netmeeting interoperam
sem problemas com este fluxo de CN (PT 19). Mas, a implementação do stack RTP
38
embutido no cliente SIP da Ubiquity versão 2.0 também não consegue receber fluxo de
mídia do Gateway Cisco, portanto não suportando o PT 19.
2.6 – Implantação de Ambiente de Telefonia IP baseado em SIP
Como cenário macro, integramos o serviço Web-To-Dial apresentado, ao nosso
ambiente heterogêneo de telefonia IP SIP/H.323 [8]. Possibilitando a qualquer
internauta realizar chamadas telefônicas IP para o nosso laboratório.
Os maiores desafios na montagem desta arquitetura foram as questões de
localização do servidor SIP e segurança. O ambiente SIP foi implantado com o uso de
um servidor SIP Proxy. Dois servidores SIP foram testados: um baseado em C++
desenvolvido pela Universidade de Columbia e outro baseado em Java desenvolvido
como parte do projeto de VOIP do NIST. Devido a descontinuidade da licença do
servidor SIP de Columbia (que passou a ter uma implementação comercial), a
dependência do mesmo de um servidor de banco de dados externo MySQL
(aumentando a possibilidade de falha) e a ausência de uma política de segurança,
optamos pela implantação do servidor SIP Proxy da NIST para nossa arquitetura.
Internet
Central TelefonicaNCE/UFRJ
RoteadorCisco 2600
Gateway de SinalizaçãoSIP/H.323
Gateway da Rede VOIPServidor Proxy SIP
Internauta
Servidor Webda SIP Client Applet
InterfaceVIC FXO
MicrosoftNetmeeting
Firewall
Ramal3354
Fig. 10 – Arquitetura do Laboratório VOIP/UFRJ
Este servidor SIP Proxy foi configurado na máquina de entrada da rede do
laboratório onde fica o filtro de pacotes (firewall) (Fig. 10). Para a localização do
servidor na rede e posterior registro, os clientes SIP internos podem adotar a
39
configuração direta do endereço do servidor proxy (como é o caso de nossa applet) ou
se tiverem conectividade multicast, poderão usar o endereço bem conhecido
sip.mcast.net (224.0.1.75) para se registrar.
voip.nce.ufrj.br _sip._udp 0 50 rio.voip.nce.ufrj.br
0 50 vitoria.voip.nce.ufrj.br
Quadro 5 – Entrada DNS SRV para SIP do laboratório VOIP com distribuição de carga
Em seguida, inserimos no DNS, uma entrada DNS SRV [48] para o serviço SIP
(Quadro 5 ao lado) do named [49]. Esta entrada permite que usuários SIP externos à
nossa rede, que queiram chamar usuários SIP internos, registrados no nosso servidor,
possam simplesmente mandar as requisição contendo o endereço sip://user@
sip.voip.nce.ufrj.br. Este tipo de entrada no DNS (named) é semelhante a configuração
de um serviço web. Usando este esquema de DNS SRV seria possível instalar um
servidor SIP Proxy na máquina RIO e outro redundante na máquina VITÓRIA, cada um
dos quais recebendo 50 % da carga de mensagens para o endereço sip.voip.nce.ufrj.br.
Com relação a segurança, todo sistema de telefonia IP sofrerá com o uso de
filtros de pacotes e números IP virtuais que estiverem instalados na rede, comum nas
universidades. No nosso caso não é diferente, pois temos um firewall ipchains para
Linux onde são definidas várias regras para o controle do tráfego de entrada e saída de
nossa rede.
A telefonia IP, tanto baseada no SIP, quanto no H.323 utiliza portas dinâmicas
UDP para transmitir seus fluxos de mídia. Estas portas são escolhidas aleatóriamente
entre quaisquer valores acima de 1024, um problema para o administrador de rede que
teria que abrir todas as portas UDP.
O servidor SIP Proxy do NIST apresenta uma solução para isto. Internamente
ele possui dois conjuntos de scripts escritos em Perl que realizam a abertura e o
fechamento de portas UDP no firewall e o suporte à sinalização e ao transporte de mídia
em endereços IP virtuais através de Network Address Translation (NAT). Estes scripts
foram escritos para o firewall iptables do Linux, com uma pequena adaptação das regras
ao ipchains, possibilitamos o funcionamento destas características no laboratório.
40
Os scripts de abertura de firewall funcionam somente quando o usuário está
registrado no servidor SIP. Para se registrar é preciso enviar uma mensagem
REGISTER, contendo a senha criptografada. Esta senha é checada com o arquivo de
senhas contido no diretório do servidor, e o registro será efe tuado. Como pré-requisito
para o funcionamento dos scripts de abertura de firewall, é preciso configurar o
parâmetro ParseSDP no servidor, pois toda vez que o servidor estiver realizando proxy
entre clientes, será preciso segmentar as mensagens SIP, e obter os valores dos IPs e
portas negociados no payload SDP. Com estes valores extraídos, o servidor executa os
scripts Perl e passa-os como referência para a abertura. No final da comunicação, o
servidor automaticamente desabilita esta regra de abertura no firewall. Caso, tenha
acontecido algum problema, e não acontecer a finalização da chamada, após um tempo
configurado no servidor, ele desabilita a regras d abertura não está mais sendo utilizada.
Configuramos um roteador/gateway (GW) Cisco 2600 com capacidade de
sinalização SIP para interoperar com a rede telefônica convencional. Ele possui
interfaces de telefonia FXS e FXO (Foreign Exchange Station e Foreign Exchange
Office, respectivamente) (Fig.11). A interface FXS permite conectar um telefone
diretamente no GW, enquanto a interface FXO é a que permite ligar o GW a uma linha
telefônica, seja ela ramal, ou tie-line. [50]. Essa linha telefônica está ligada diretamente
à central telefônica (PBX NEC NEAX 2400) CCMN/UFRJ. Para suportar o SIP,
instalamos o IOS (sistema operacional do roteador) versão 12.2, com 64 MB de
memória RAM. Na configuração inicial para o ambiente SIP, mostrada no Quadro 6,
temos a interface FXO 1/0/1, e um plano de discagem simplificado.
2.6.1 – Configurações do Gateway SIP/PSTN Cisco 2600
Fig. 11 - Interfaces FXS e FXO
41
Os planos de discagem do GW Cisco
2600 (chamados de dial-peers) permitem rotear
as chamadas telefônicas IP para a telefonia
convencional, através da combinação de um
número chamado com seu padrão ou máscara.
Em caso de sucesso nesta combinação a ligação
segue pela interface especificada no dial-peer.
Criamos um dial-peer que tem como máscara o
prefixo 55212598...., se uma chamada de
telefonia IP tivesse como endereço de destino
um número com este padrão, o gateway
redirecionaria a chamada para a porta 1/0/1, que no caso é a interface FXO ligada a
central telefônica, possibilitando ligações locais a ramais da UFRJ via telefonia IP.
O GW Cisco 2600 está configurado como SIP User Agent (sip-ua), podendo
receber ligações SIP diretamente, como se fosse outro cliente SIP qualquer. Imagine,
por exemplo, que estamos usando algum dispositivo SIP e buscando a url
sip://[email protected]. O GW Cisco recebe a sinalização INVITE deste
cliente, e responde prontamente com resposta 100 Trying, para inibir as retransmissões
de mensagens SIP. Caso ele encontre o número procurado no seu plano de discagem, ele
envia o status 183 Session Progress, fazendo com que este telefone (um ramal da UFRJ)
seja tocado na rede telefônica. Quando o telefone for atendido, a sinalização continuaria
com o envio de 200 OK do GW para o dispositivo chamador e ficaria esperando o ACK
deste chamador.
Monitoramos uma sessão SIP para mostrar alguns dos parâmetros negociados na
sinalização, conforme Quadro 7. A mídia negociada foi o codificador G.711 ? law, e os
IPs/portas de mídias das partes são “146.164.247.203/20836” (origem), e
“146.164.247.202/10000” (destino). O número chamado foi o 552125983354 pelo
usuário cesar da rede SIP.
voice rtp send-recv ! voice-port 1/0/1 cptone BR description Linha Telefonica FXO ! dial-peer voice 2598 pots destination-pattern 55212598.... port 1/0/1 ! dial-peer voice 1212939 voip destination-pattern 1212939.... session protocol sipv2 session target ipv4:128.59.19.62 ! sip-ua !
Quadro 6 – Configuração Básica do Roteador Cisco 2600 para Suporte SIP
42
03:25:07: The Call Setup Information is : State of The Call : STATE_ACTIVE Calling Number : cesar Called Number : 552125983354 Negotiated Codec : g711ulaw Negotiated Codec Bytes : 160 Negotiated Dtmf-relay : 0 Source IP Address (Media): 146.164.247.203 Source IP Port (Media): 20836 Destn IP Address (Media): 146.164.247.202 Destn IP Port (Media): 10000 Destn SIP Req Addr:Port : 146.164.247.202:5060 Destn SIP Resp Addr:Port : 146.164.247.202:5060 Destination Name : 146.164.247.202
Quadro 7 – Mensagem de Status SIP do Cisco 2600 obtida com o comando: debug ccsip all
No caminho inverso, de ligações vindas da rede telefônica para o ambiente SIP,
é preciso configurar outro tipo de dial-peer chamado dial-peer voip (Quadro 6).
Configuramos um dial-peer voip para a Universidade de Columbia conforme descrito
por [51], na tentativa de acessar os ramais telefônicos com o padrão 1 (212) 939 xxxx
(respectivamente os códigos dos EUA, Nova Iorque e do PBX do depto. de computação
da Universidade Columbia). Alguém usando a linha FXS e discando 1212939-XXXX,
faria com que o GW gerasse sinalização SIP INVITE (session protocol sipv2) para o IP
128.59.19.62. Entretanto esta configuração não pode ser testada operacionalmente, pois
o servidor SIP de Columbia não se encontra mais neste endereço IP.
43
CAPÍTULO 3
IMPLANTAÇÃO DE AMBIENTE H.323 E TESTES DE INTEROPERABILIDADE DE VOZ SOBRE IP NA INTERNET2
Uma das primeiras premissas desse capítulo é obter subsídios práticos e
experiência operacional em telefonia IP H.323, de forma a melhorar a proposta de
arquitetura universal de telefonia IP. Neste capítulo, descreveremos a implantação de
um ambiente baseado no H.323 conduzido no laboratório VOIP da UFRJ.
O capítulo está organizado em 5 seções. Na seção 3.1, realizamos uma breve
revisão das atualizações recentes da padronização de telefonia IP da ITU-T. Na seção
3.2 temos a apresentação dos programas utilizados e a implantação do ambiente no
laboratório. Na seção 3.3 apresentamos a implantação do Gateway H.323/PSTN Cisco
2600. Na seção 3.4, mostramos como interoperar o software gatekeeper com o gateway.
Por fim na seção 3.5, veremos os testes realizados na interoperação com outros sites de
telefonia IP da Internet2, os problemas encontrados e as possíveis soluções.
3.1 – Evolução da Recomendação H.323
A primeira versão da recomendação H.323 foi publicada em 1996 [4], projetada
para a comunicação multimídia para redes locais sem garantia de serviço, onde
empresas pioneiras na área, como VolcalTec®, viram a oportunidade de também usá- la
para redes de maior abrangência como a Internet, supreendentemente esta padronização
funcionou bem. Mais tarde, reconhecendo que a recomendação H.323 necessitava de
maior performance, escalabilidade e aprofundamento de questões como segurança e
serviços suplementares, a ITU-T lançou a versão 2 deste padrão, em 1998 [4].
44
Na versão 2 do padrão H.323 foi introduzido o esquema FastStart de
estabelecimento de chamada, para melhorar o tempo de resposta e o tunelamento das
PDUs H.245 através do canal H.225/Q.931. Não havendo mais a necessidade de dois
sockets TCP/IP, um para o canal de sinalização (Q.931/H.225.0 [52]) e outro para o
canal de controle (H.245 [53]). Também foi incorporado ao grupo de recomendações
referenciado pelo H.323, o padrão H.235 que lida com a segurança, autenticação,
integração e privacidade dos dados.
Em setembro de 1999, a ITU-T lançou a recomendação H.323 na sua versão 3
[4], com poucas melhorias no que já tinha sido estabelecido na versão 2, mas
introduzindo novas e poderosas características, principalmente através dos anexos E e G
do H.323. O anexo E diz respeito ao uso do protocolo de transporte UDP para a
sinalização das chamadas entre os terminais H.323 (endpoints) e gatekeepers. Já o
anexo G [54] provê aos gatekeepers H.323 a habilidade de realizar resoluções de
endereço e troca de tarifas (custos das chamadas) de uma forma escalável (através de
Border Elements), que permite a construção de redes realmente grandes de comunicação
H.323 em nível internacional. A reclamação dos fabricantes de equipamentos de
telefonia IP de que o H.323 é muito grande para ser embutido em pequenos dispositivos
foi contornada com a introdução do Simple Endpoint Type, ou SET, presente no anexo
F. Um dispositivo SET utiliza uma fração da especificação H.323 e ainda assim prôve a
capacidade de estabelecimento de chamadas de áudio com outros terminais H.323.
A versão 4 do H.323 foi lançada em novembro de 2000 e contém uma série de
melhorias [4] (Fig. 12 a seguir) em áreas estratégicas como confiabilidade,
escalabilidade e flexibilidade. Estes melhoramentos ajudam no desenvolvimento de
soluções de videoconferencia e gateway mais escaláveis.
O procedimento de Alternate Gatekeepers (Fig. 12-A) já havia sido introduzido
pela versão 2 do H.323, mas não fora documentado, somente agora na versão 4 é que
ele está totalmente descrito. Pelo uso de Alternate Gatekeepers, os terminais H.323 são
capazes de continuar funcionando em face de uma ou mais falhas vinculadas aos GKs, e
que resultariam em perdas de chamadas. Na Fig. 12-B temos o uso dos “relatórios de
capacidades” enviados pelos GWs, permitindo aos GKs selecionar o GW com maior
capacidade livre para estabelecer a ligação.
45
A mudança mais importante na recomendação H.323 versão 4 foi quanto a
necessidade do aumento da escalabilidade do gateway para operar como central
telefônica. Para expandir a quantidade de interfaces suportadas foi preciso redefinir o
modelo tradicional de gateway (Fig. 12-C), onde no mesmo equipamento tínhamos o
controle da chamada (MGC – Media Gateway Controller) e o controle de media (MG –
Media Gateway), na decomposição do gateway, são separadas as funções de MGC e
MG. Desta forma, múltiplos MGs podem ser adicionados e darão maior capacidade ao
novo modelo decomposto. A comunicação entre o MGC e os MG deve ser feita através
do padrão H.248/MGCP, uma padronização conduzida em conjunto pela IETF e ITU-T.
Gatekeeper
Gatekeeper
Gatekeeper
Endpoint(Netmeeting)
(A) Alternate Gatekeepers
Gatekeeper Gatekeeper Gatekeeper
Gateway23%
Gateway64%
Gateway77%
Gateway36%
(B) Endpoint Capacity Reporting
MGC
MG
MGC
MGMGMG
MGMGMG
MGMGMG
GatewayComposto
(C) Decomposição do Gateway
GatewayDecomposto
Fig. 12 – Novas características do H.323 v4
(A) Procedimento de uso de gatekeepers alternativos, (B) Endpoints podem relatar sua capacidade aos GKs,
(C) Decomposição do Gateway com H.248.
46
3.2 – Pesquisa sobre os programas do projeto OpenH323
Realizamos uma pesquisa entre vários softwares clientes e servidores baseados
no H.323, e montamos nossa arquitetura de telefonia IP baseada em H.323 usando um
conjunto de ferramentas de código fonte aberto baseadas no projeto OpenH323 [17].
Estas ferramentas têm uma grande flexibilidade, visto que é possível manipular seu
código fonte, e a comunidade que as desenvolve também é grande e com uma forte
equipe de suporte para solucionar as dúvidas.
Estas ferramentas usam a Pwlib e OpenH323, bibliotecas do projeto OpenH323.
Estas bibliotecas contém todas as funcionalidades previstas pelas recomendações
H.323, H.225.0, Q.931, H.235, H.245 [52][53][55], RTP [2], mapeadas em objetos,
implementando também vários codificadores e decodificadores de mídia como G.711,
GSM, MS-GSM, LPC (de áudio), H.261, H.263 (de vídeo), todos padrões da ITU-T.
Segue uma breve descrição destas ferramentas:
?? Ohphone:
É um terminal H.323 completo, tendo compatibilidade com versões de 1 a 4 do
padrão H.323 ITU-T, portanto, podendo interpretar as mensagens FastStart e
tunelamento de PDUs H.245. É das poucas implementações pesquisadas que
possuem serviços suplementares H.323 (Call Hold e Call Transfer). Não possui
interface gráfica amigável, sendo que o usuário deve inserir parâmetros e
comandos diretamente na shell. Compilamos este terminal para as plataformas
Windows, Linux, Solaris, FreeBSD, e
MacOS X com sucesso. Também está
disponível um terminal com interface
gráfica, e igual funcionalidade, chamado
openphone (Fig. 13). Entretanto este não
possui versões para Unix, funcionando
somente no Windows.
?? Openam:
“Answer Machine”, é um terminal H.323 que faz o papel de secretária
eletrônica. Ele fica esperando conexões na porta de sinalização, capturando as
Fig. 13 –Programa openphone em
execução
47
possíveis chamadas. Uma vez que um SETUP chega, ele automaticamente
responde com CONNECT, e lê um arquivo de mídia pré-gravado contendo a
mensagem sonora da secretária, para ser enviado via RTP. Logo em seguida, o
openam começa a capturar e redirecionar para outro arquivo a fala do usuário
chamador. Podem ser associados scripts ao openam para realizar tarefas simples
como mandar o arquivo com a mensagem gravada para o email do dono desta
caixa postal de voz.
?? OpenMCU:
Servidor de Conferência do H.323, faz a mixagem/reflexão dos fluxos RTP
oriundos de vários terminais H.323, para um só fluxo de saída. É possível
inclusive utilizar o Netmeeting, inclusive, para fazer uma conferência de áudio e
vídeo.
?? PSTNGw:
Este programa tem a capacidade de interoperar com a rede telefonica convencional,
usando uma placa especial de telefonia como a Linejack [56], fazendo o papel de
gateway H.323/PSTN. Como um dos sub-projetos do OpenH323, os
desenvolvedores criaram um driver Linux para a Linejack, sendo possível portanto
montar um gateway de telefonia a baixíssimo custo.
Uma característica comum de todos os softwares descritos, é que eles
conseguem logar todas as atividades em termos de sinalização, negociação de mídia,
transmissão de mídia e estatísticas em arquivos de log (formato texto). Utilizamos muito
esta funcionalidade, para entender e resolver problemas no ambiente H.323.
A Equivalence, mantenedora do projeto OpenH323, também disponibiliza o
código fonte de um servidor gatekeeper, chamado opengk, outra ferramenta disponível.
Entretanto, este projeto opengk é bastante recente, e o conjunto de funcionalidades
oferecido ainda é pequeno, veremos na seção 3.2.2.1 que optamos por usar outra
implementação, também baseada nas bibliotecas do OpenH323, desenvolvidas por outro
grupo para fazer o gerenciamento de nossa rede de telefonia IP.
48
Como visto anteriormente, as ferramentas do projeto OpenH323 têm uma
excelente portabilidade e optamos compilar estas nas plataformas disponíveis do
laboratório (Windows, Linux e Solaris). O processo de compilação é o padrão de vários
outros projetos de licença GNU (Free Software). Usando o conjunto autoconf/
configure/ make para obter informações do sistema e a partir destas criar o binário
apropriado àquela plataforma. No final da fase de compilação são gerados dois arquivos
binários do mesmo software, um para ser usado como versão de produção (release) e
outro como versão de depuração (debug).
As bibliotecas pwlib e openh323 devem ser compiladas primeiro, visto que são a
base para as demais ferramentas. Ao final temos as bibliotecas compartilhadas
resultantes (pwlib.dll, ptlib.dll e openh323.dll, no ambiente Windows). As demais
ferramentas então podem ser compiladas, incorporando ou não as bibliotecas no seu
código binário.
Após esta fase de compilação, iniciamos alguns testes de interoperação entre o
terminal H.323 Netmeeting da Microsoft (software largamente utilizado para
video/audioconferências) e as ferramentas do projeto OpenH323, com sucesso. Esta
interoperação nas fases iniciais foi feita fazendo as chamadas diretamente pelo endereço
IP do destino. Também testamos os aplicativos openam e openmcu no laboratório.
Para melhor organizar e gerenciar um ambiente H.323 é preciso implantar um
servidor gatekeeper, que faz o controle de admissão das chamadas e permite associar
apelidos (alias) à usuários registrados. Estudamos três implementações de código fonte
aberto, todas as três baseadas nas bibliotecas do projeto OpenH323.
3.2.1 – Implantação e Testes das Ferramentas H.323 no Laboratório VOIP
3.2.2 – Estudo sobre Gatekeepers H.323 baseado no OpenH323
49
3.2.2.1 – Servidor Opengatekeeper
A implementação escolhida Opengatekeeper foi desenvolvida inicialmente pela
Egoboo, empresa inglesa especializada em consultoria na área de telefonia IP, sob a
licença MPL (Mozilla Public License, que permite que este código fonte seja
incorporado em produtos comerciais, desde que as modificações feitas também fiquem
disponíveis sob a mesma licença). Na época de sua implementação, não existiam outros
gatekeepers usando as bibliotecas do OpenH323. A Egoboo mantém o projeto no site
SourceForge [10], e atualmente ele está estacionado do ponto de vista de criação de
novas características.
O Opengate (nome do arquivo binário do Opengatekeeper) possui as
capacidades de: rotear chamadas via modo GK-routed (onde o GK faz o redirecionando
das mensagens como intermediário da comunicação), suportar o uso de prefixos para
acessar gateways, suportar diversos tipos de alias H.323, logar as atividades de
chamadas e registros, encaminhar pesquisas de endereços para GKs vizinhos.
O programa (Fig. 14) tem 4 classes básicas: Environ (que engloba as tabelas
onde estão armazenandos: terminais registrados – EndpointTabl, e as chamadas em
curso – CallTabl), MulticastThread e RasThread (que englobam o processamento do
protocolo RAS – RasServer), e CallThread (usada para realizar chamadas no modo GK
routed).
As classes RasThread e MulticastThread são ativadas assim que o programa se
inicia, e estão preparadas para receber mensagens de sinalização RAS pelas portas
TCP/UDP 1719 (RAS Unicast) e UDP 1718 (RAS Multicast), respectivamente.
Quando uma mensagem RAS chega ao sistema, é executado o método
ReadRasReq que encapsula os bytes da requisição em um objeto. A diferença entre as
duas classes RasThread e MulticastThread é que uma trabalha escutando em uma das
interfaces de rede do computador, enquanto a outra usa o endereço multicast bem
conhecido 224.0.1.41 para receber as requisições RAS.
50
Fig. 14 – Diagrama de Classes do Opengatekeeper
Após a mensagem ter sido recebida e devidamente classificada, ela é passada
para a classe RasServer que contém todos os procedimentos para a execução da
máquina de estados do protocolo RAS. Os métodos OnRRQ, OnARQ, OnLRQ, etc. são
usados para tratar as requisições assim que elas tiverem sido diferenciadas no método
handleRasRequest. Normalmente o processamento destes métodos acaba acionando
outro métodos de confirmação (doACF, doRCF) ou rejeição (doARJ, doRRJ)
dependendo da mensagem RAS sendo trabalhada.
Se o Opengate estiver configurado para fazer chamadas roteadas (modo GK
routed), ele dispara o uso da CallThread, esta thread tem a capacidade de capturar as
mensagens Q.931 Setup/Connect/Release que estão vindo de um terminador chamador,
e enviá- la para o terminal chamado, como se fosse um túnel. Ela também tem
procedimentos para suportar o envio da sinalização H.245 dentro de mensagens H.225
Facility através do método handleTunneledH245 ( ), uma característica das versões mais
recentes do H.323.
O objeto Environ, representa o ambiente de execução, onde fica armazenado na
memória os parâmetros do arquivo de configuração, como a tabela de GKs vizinhos e
51
prefixos de gateways. Também tem associado a ele o objeto de Log, que cria um
arquivo e vai anexando a sinalização manipulada, em formato texto, pelo servidor.
3.2.2.2 – Servidor OpenH323Proxy
Outro gatekeeper estudado foi o openh323proxy [16], desenvolvido pela Abdus
Salam International Centre for Theoretical Physics, centro de pesquisa localizado em
Trieste, Itália. Ele foi desenvolvido para solucionar problemas de firewall no ambiente
H.323. É baseado no projeto Opengatekeeper, mantendo todas as funcionalidades do
mesmo, e estendendo uma característica de redirecionamento de mídia (RTP proxy).
Ele permite rotear o tráfego RTP (áudio e vídeo) e o tráfego T.120 (dados
compartilhados) através do gatekeeper, sem que estes fluxos sejam trocados diretamente
entre os terminais. Entretanto, este projeto está com suas chamadas às bibliotecas
OpenH323 desatualizadas não sendo possível compilá- lo com as versões mais novas
destas bibliotecas.
As mudanças mais significativas em relação ao projeto original Opengatekeeper
estão nas classes CallThread e RasServer. Na classe CallThread, quando estamos
trabalhando com o modo GK routed, temos um método modificado que atua na camada
de negociação de mídia H.245 trocando os endereços IP especificados pelas partes
envolvidas na comunicação, pelo endereço do servidor. Esta mudança é verificada no
método handleH245 ( ). Este método ativa uma thread chamada H245Thread_Proxy,
que a partir de endereços especificados no arquivo de configuração, lidos na classe
ProxyTbl (tabela de redirecionamento de mídia) permite trabalhar com tradução de
endereços (NAT) e Firewall. Com estes endereços de redirecionamento, este software
pode abrir os canais de mídia (um para cada lado) através dos métodos handleOpenRTP
( ) e handleOpenRTPAck ( ) formando o duto para a mídia.
Outra mudança é na classe RasServer onde foram incorporadas funcionalidades
de busca de servidores GK através de DNS (classe DNSUtils), sendo uma nova opção
de busca por GKs vizinhos quando utilizamos endereços do tipo h323 url-id ou email-
id, nos softwares terminais H.323.
52
3.2.2.3 – Servidor OpenGK
O último servidor pesquisado foi o OpenGK [17] desenvolvido pela empresa
australiana Equivalence Pty, mantenedora do projeto OpenH323. Este projeto começou
muito lentamente, mas é hoje em dia, o projeto de gatekeeper com maior atividade.
Entretanto, possui apenas o modo de chamada direta implementado (GK Direct Call
Mode – quando o GK repassa ao cliente chamador o IP do cliente chamado, sem fazer
mais nenhuma intermediação). Ele também não pode configurar gatekeepers vizinhos
para propagar buscas, uma importante desvantagem. Por outro lado possui suporte a
serviço Web e objetos de criptografia e autenticação segundo o padrão H.235 [55].
A fig. 15 ilustra o diagrama de classes do opengk.
Fig. 15 – Diagrama de Classes do OpenGK
O projeto opengk utiliza das bibliotecas de serviço HTTP (Pwlib) para prover
uma forma de configuração baseada na Web diferente dos outros projetos que usam
arquivos de configuração. O servidor opengk fica esperando requisições HTTP. Ele
configura no método onStart (logo que é carregado), todo o domínio www do GK
através do objeto httpNameSpace (Pwlib), este espaço de nomes é constituído de várias
páginas web criadas na memória do servidor: página de configuração, página de
cadastramento de usuário e senhas, e página do status de usuários logados/chamadas em
curso.
53
A classe MyEndpoint representa o GK como um tipo especial de terminal H.323
herdando o método createConnection da classe H323Endpoint. Agregado a esta temos a
classe especializada MyGatekeeperServer onde serão executados os métodos de
manipulação do protocolo RAS, herdado da classe H323GatekeeperServer. É possível,
usando as classes do OpenH323 reescrever parte do método sem comprometer o seu
funcionamento pelo uso de polimorfismo, como é o caso do método OnAdmission.
Um ponto forte nesta implementação é que ela incorpora a autenticação e
criptografia previstos na recomendação H.235. Na herança da classe
H323GatekeeperServer, a classe MyGatekeeperServer herda o método OnRegistration()
que só registra os usuários que passarem pelo teste do método interno GetAuthenticators
( ), que extrai da mensagem RRQ o parâmetro de autenticação e compara este com a
senha do usuário previamente configurada via Interface Web do GK.
Compilamos e instalamos o software opengatekeeper nas plataformas Windows
e Linux, e configuramos o mesmo para realizarmos testes locais. O objetivo era
trabalhar diretamente com os apelidos, ou alias (h323- id) dos usuários, ao invés de fazer
a chamada via endereço IP. Monitorando estas ligações via arquivos de logs gerados
pelos programas.
Como metodologia utilizada para detecção de erros, utilizamos o programa
openam (open answer machine) pois ele é uma solução interessante para testes de
comunicação em nível remoto, não sendo necessário uma segunda pessoa para a
realização dos testes. O openam permite logar as mensagens da sinalização sendo que a
máquina alvo não precisa sequer ter placa de captura de áudio instalada, visto que o
openam trabalha com um arquivo de mensagem pré-gravada. Isso facilita isolar a
funcionalidade da arquitetura de telefonia IP dos problemas que podem acontecer nos
dispositivos (hardware/driver) de áudio/vídeo instalados.
3.2.3 – Implantação de Ambiente H.323 no Laboratório VOIP
54
Usamos as seguintes configurações locais
no GK instalado no ambiente H.323, indicadas no
Quadro 8. [System] representa o bloco com as
configurações de sistema onde:
Local Address:
endereço IP da interface de rede onde o
servidor estará ouvindo requisições;
IsGKRouted:
se configurado com 1 (verdadeiro) indica
que o servidor estará usando o modo GK-routed de roteamento de sinalização;
RouteH.245:
configurada como verdadeiro indica que também estará sendo usado o
roteamento da sinalização H.245 (canais lógicos) via GK.
Gatekeeper Id:
É a informação do campo GatekeeperIdentifier, para checar se certa mensagem
RAS é para aquele GK, quando ele estiver ouvindo o grupo multicast.
Na seção [Neighbours] deve ser colocada a tabela de gatekeepers vizinhos. O
processo de colocar um GK como vizinho é equivalente a dizer que se a localização de
um usuário, encaminhada para este GK, não for encontrada, ele pode disparar uma
busca perguntando aos seus vizinhos até completar a localização deste usuário chamado.
Inserimos as linhas VODUFMG=150.124.32.45 e PHARUCLA=phar.cs.ucla.edu,
porque nesta fase de implantação colaboramos tanto com o grupo de Vídeo sob
Demanda da UFMG, quanto com o Network Research Laboratory, UCLA (EUA), para
a construção de uma infra-estrutura de telefonia IP.
A última seção [Log] diz respeito ao monitoramento das mensagens que passam
pelo GK. O parâmetro Level=2 indica o nível de detalhamento das mensagens, neste
caso é possível até ver os cabeçalhos das mensagens H.225/Q.931/H.245.
A opção de utilizar o modo GKRouted e o roteamento das mensagens H.245 foi
escolhida estratégicamente, porque deste modo o servidor GK poderia logar sozinho
toda a sinalização envolvida entre os terminais H.323. Ao invés de termos que extrair
[System] Local Address=146.164.247.202 IsGKRouted=1 Route H245=1 Gatekeeper Id=UFRJGK [Neighbours] VODUFMG="150.124.32.45" PHARUCLA=phar.cs.ucla.edu [Prefixes] [Log] Level=2
Quadro 8 – Configuração do Opengatekeeper Local
55
log por log de cada terminal H.323 estas mensagens e organizarmos cronológicamente.
Isto facilitou muito o trabalho de depuração e entendimento do ambiente.
Quando colocamos o servidor em produção, preparamos alguns procedimentos
administrativos para auxiliar na gerência. Desenvolvemos um script em perl agregado
ao servidor Web Apache, para exibir os logs do servidor GK em testes remotos, de
modo a termos um controle mais preciso da utilização do GK. Com base nas
informações de logs, é possível montar um processamento para contabilizar as ligações
efetuadas e o tempo de duração de cada ligação. O tempo da ligação deve começar
assim que o terminal H.323 envia a mensagem Q.931 Setup, e terminar quando ele
receber/enviar a mensagem de Release Complete. Sabemos que estamos lidando com a
mesma ligação pelo cabeçalho callReference (número que referencia uma única
chamada). Nestes pontos podemos obter os tempos absolutos (em segundos) do arquivo
de log e calcular a duração da ligação (Quadro 9 abaixo).
01:05:05 16/01/2002 Recv 128.200.9.21:3174 Q.931 { callReference = 25930 messageType = Setup IE: Display = { 4d 61 6e 75 65 6c 20 41 6e 69 64 6f 00 Manuel Anido. } IE: Called-Party-Number = { 81 35 35 32 31 32 32 34 32 38 30 30 34 .55212598XXXX } 01:15:27 16/01/2002 Recv 128.200.9.21:3174 Q.931 { callReference = 25930 from = originator messageType = ReleaseComplete }
Quadro 9 – Trecho do Log do Opengatekeeper usado para calcular o tempo da ligação
3.2.4 – Logando Ligações no Ambiente UFRJ
56
3.3 – Implantação do Gateway H.323/PSTN Cisco 2600
Em meados de outubro de 2001 recebemos, em regime de empréstimo pela
RNP2, um roteador Cisco 2600 com capacidades de rotear voz para testes com o grupo
de VOIP da Internet2. Ele foi configurado com a versão 12.2 do IOS [57] de modo que
trabalhasse tanto com a sinalização SIP/H.323, suportasse listas de acesso (Access
Control List – filtro de pacotes do roteador) e opções avançadas de qualidade de
serviço. Este equipamento tem 4 interfaces de rede, sendo duas delas interfaces
Ethernet, e duas seriais. Além de outras quatro interfaces de voz (2 FXS/2 FXO). As
interfaces de voz permitem fazer a interoperação entre a LAN e a PSTN (Fig 16).
Na interface FXS conectamos um aparelho telefônico diretamente ao roteador
(#3190), provendo tom de discagem para o mesmo (Fig. 16). Já nas interfaces FXO
foram conectadas duas linhas telefônicas diretamente ao PBX CCMN/NCE. Cada
interface FXO poderia ser configurada na central como ramal convencional ou uma
linha tie-line [50]. A operação tie-line permitiria que chamadas para os ramais #3186 e
#3191 pudessem ser capturadas pelo roteador Cisco 2600, e o roteador sinalizaria um
segundo tom de discagem, para capturar novos números (modo direct-inward dialing –
DID) e rotear a ligação para a telefonia IP partindo-se da telefonia convencional.
RoteadorCisco 2600
Central TelefônicaCCMN/NCE
Telefone Virtual3190
Hub 10/100
Gatewayda Rede
(máquina RIO)OpenGatekeeper(máquina vitória)
Internet
inteth0/0
FXO3186
FXO3191
TroncoTelefonico
UFRJ
FXS3190
Fig. 16 – Arquitetura de Telefonia IP do Laboratório VOIP
57
Para prover interoperação com a
telefonia convencional, é preciso configurar as
interfaces apropriadamente, e criar os plano de
discagem (dial-peers). Configuramos as duas
interfaces FXO em dois ramais da UFRJ
(#3186 e #3191) e plugamos um telefone ao
roteador. O telefone foi configurado com um
número de ramal não-utilizado (#3190), de
modo a não confundir os usuários da Internet,
quando quisessem chamar diretamente por este
telefone.
Nosso plano de discagem abrange na
rede telefonica convencional (PSTN) apenas
os números dos prefixos da UFRJ,
adicionamos o número 5521 (código telefônico
internacional do Brasil/Rio de Janeiro), para
manter o padrão telefônico.
O Quadro 10 mostra esta configuração.
O bloco voice-port 1/0/0, configura a interface
FXO ligada ao ramal #3191, enquanto que a
voice-port 1/0/1 está ligado ao ramal #3186.
Cada uma destas interfaces FXO está
configurada para gerar tom de discagem padrão brasileiro (cptone BR). Os outros voice-
port (1/1/0 e 1/1/1) são as interfaces FXS, no nosso ambiente, instalamos apenas 1
telefone #3190, no voice-port 1/1/1.
O plano de discagem para a UFRJ foi criado usando os prefixos 55212598.... e
55212562...., tivemos que colocar dois dial-peers por prefixo, para que caso uma das
interfaces de saída FXO estivesse ocupada, automaticamente, o outro dial-peer seria
usado.
O último dial-peer é um redirecionamento específico para quem tenta da
Internet ligar para o ramal #3190, ele é direcionado para a interface 1/1/1, o telefone
3.3.1 – Configurações Iniciais do Roteador Cisco 2600
voice-port 1/0/0 cptone BR connection plar 552125983190 description Linha Telefonia 2 FXO 3191 ! voice-port 1/0/1 cptone BR connection plar 552125983190 description Linha Telefonia 1 FXO 3186 ! voice-port 1/1/0 ! voice-port 1/1/1 cptone BR description Telefone Virtual 2598 3190 ! dial-peer voice 1 pots destination-pattern 55212598.... port 1/0/1 ! dial-peer voice 2 pots destination-pattern 55212598.... port 1/0/0 ! dial-peer voice 3 pots destination-pattern 55212562.... port 1/0/1 ! dial-peer voice 4 pots destination-pattern 55212562.... port 1/0/0 ! dial-peer voice 5 pots destination-pattern 552125983190 port 1/1/1 Quadro 10 – Configuração das Interfaces
e Planos de Discagem do Gateway Cisco 2600
58
virtual ligado diretamente ao roteador Cisco 2600. As interfaces FXO 1/0/0 (#3186) e
1/0/1 (#3191) estão redirecionando todas as ligações que vierem para elas, para o
número 552125983190 (connection plar) e por conseguinte, quem ligar para estes
ramais será redirecionado para o telefone virtual da interface FXS 1/1/1 (#3190).
Com esta configuração já é possível realizar ligações da Internet para a rede
telefônica convencional. O software Netmeeting por exemplo, pode ser configurado
para acessar este gateway, enviando um número telefônico e fazendo a ligação. Mas,
para fazer esta ligação é preciso conhecer previamente o endereço IP da interface
ethernet deste gateway. Além disso, não existe nesta configuração simples nenhum
mecanismo que controle do uso do Gateway, ou seja, usuários de posse dessa
informação podem fazer ligações grátis a partir deste ambiente. O plano de discagem
com máscara 55212598.... limita a área de abrangência das ligações de usuários da
Internet para somente ramais da UFRJ.
Quando começamos a interagir com o grupo de trabalho VOIP da Internet2,
principalmente com os sites de telefonia IP da AARNET (Rede Nacional de Pesquisa
Australiana), TAMU (Universidade A&M do Texas), Universidade de Indiana, SLAC
(Universidade de Stanford), CESNET (Rede Nacional de Pesquisa da Rep. Tcheca),
verificamos a necessidade da utilização do anúncio de nossos prefixos via GK. Como
não dispunhamos de GK da Cisco (usado por todos estes outros sites), decidimos fazer a
interoperação usando nosso próprio GK (Opengate) baseado em software já instalado
no laboratório (Fig. 16).
3.4 – Interoperação Opengatekeeper e Gateway H.323/PSTN Cisco
Todo gateway (GW) é um dispositivo para fazer a interoperação entre duas
arquiteturas. No caso do GW H.323/PSTN, estamos conectando a rede Internet (via
sinalização H.323) à rede telefonica convencional. Na arquitetura H.323, o gateway
pode ser visto como um tipo especial de terminal, sem a necessidade de gerenciamento.
Outros terminais como Netmeeting, openphone podem fazer ligações diretamente a este
pela porta TCP 1720 (sinalização H.225/H.245), assim como outros gateways poderiam
estar configurados para prover uma comunicação ponto-a-ponto entre GWs.
59
Podemos aumentar o nível de organização ao autenticar e registrar o GW
H.323/PSTN à um GK, de modo a anunciar seus número telefônicos. Para fazer isso, é
preciso verificar a configuração do endereço IP do GK, e qual o seu
GatekeeperIdentifier para preencher as configurações no GW Cisco 2600.
Interface Ethernet0/0 description connected to Internet ip address 146.164.247.203 255.255.255.192 full-duplex h323-gateway voip interface h323-gateway voip id UFRJGK 146.164.247.202 1719 h323-gateway voip h323-id [email protected] h323-gateway voip tech-prefix 55212598 h323-gateway voip tech-prefix 55212562 h323-gateway voip bind srcaddr 146.164.247.203 ! gateway !
Quadro 11 – Configuração da Interface Gateway para Registro no GK
A configuração de GW é dependente da interface ethernet que queremos
registrar, como porta de acesso aos números telefônicos. O Quadro 11 ilustra esta
configuração. Os comandos h323-gateway são os que preparam a requisição RRQ
(RAS) contendo o anúncio dos número telefônicos ao GK. O id é o identificador do GK
que deve ser o mesmo configurado no GK. A informação h323-id é o alias (apelido)
deste GW registrado no GK. E os números tech-prefix são os prefixos telefônicos a
serem anunciados nos quais o GW provê acesso. O comando h323-gateway bind
contém o endereço IP que o GW colocará no cabeçalho srcSignallingAddress em suas
mensagens RAS. E a última linha de configuração gateway é a mais importante, ela é
que vai ativar o processo de anúncio dos prefixos.
Com este novo nível de organização, os usuários que estiverem registrados no
GK, podem simplesmente discar um número telefônico e serão redirecionados para o
GW, sem precisar conhecer previamente qual o endereço IP deste GW.
No passo seguinte, configuramos o nosso GW de modo que a partir do ramal
FXS pudessemos realizar ligações de telefonia IP, para os sites do grupo VOIP da
Internet2. Isso é uma emulação enquanto não dispomos de uma linha tie- line.
3.4.1 – Configuração de Dial -Peer para os Sites de VOIP da Internet2
60
Identificamos dois tipos de dial-peers que
realizam ligações de telefonia IP: os que realizam
ligações entre GWs diretamente, e os que realizam
ligações passando pelo GK. O quadro 12,
apresenta os dial-peers da Internet2. Os dois
primeiros (1 e 2) dial-peers são respectivamente
para p SLAC (Stanford Linear Accelerator
Center), e CESNET (Czech National Research
Network). Eles apontam diretamente para os GWs
destas instituições fazendo uma comunicação
ponto-a-ponto. Os outros dois dial-peers (3 e 4)
utilizam da infra-estrutura do GK para fazer a
ligação (AARNET e TAMU).
O exemplo da utilização dos dial-peers 3 e 4 seria a seguinte. Um usuário pega o
telefone ligado ao roteador, e disca o número 61262766223. Este número é então
comparado com o conjunto de dial-peers, que casa com a entrada 3 voip (a palavra voip
na configuração de dial-peer indica que a ligação será enviada para a Internet). Ao invés
de configurar o IP do GW diretamente, como é feitos nos dial-peers 1 e 2, o comando
session target ras, indica que o GW deve enviar sinalização RAS para o GK, ao qual
está registrado, para completar sua ligação. O GW então prepara uma mensagem de
ARQ contendo o número desejado, e envia para o GK. Nosso GK tem uma entrada na
tabela de GK vizinhos [neighbours] para o GK da Austrália. Portanto, quando o
Admission Request (ARQ) chegasse ao nosso GK, ele faria a verificação de que o
prefixo não está registrado localmente, e dispararia um Location Request (LRQ) para
todos os vizinhos configurados. A resposta Location Confirm (LCF) contém o endereço
IP de outro GW da Austrália associado aquele número discado. Esta resposta de
confirmação é encaminhada ao GW na forma de um Admission Confirm (ACF) e este
então pode prosseguir no estabelecimento de chamada diretamente.
dial-peer voice 1 voip destination-pattern 1650926.... session target ipv4:134.79.232.1 codec g711ulaw ! dial-peer voice 2 voip destination-pattern 42022435.... session target ipv4:195.113.156.179 codec g711ulaw ! dial-peer voice 3 voip destination-pattern 61262766... session target ras codec g711ulaw ! dial-peer voice 4 voip destination-pattern 1979845.... session target ras codec g711ulaw Quadro 12 – Configuração dos Dial-
peers da Internet2
61
3.5 – Testes de Interoperação com Sites VOIP da Internet2
Fizemos vários testes de interoperação com os sites relacionados na seção
anterior. As ligações entre GWs (SLAC e CESNET) aconteceram sem problemas.
Entretanto, tivemos problemas para implementar a solução com o GK. Como haviamos
comentado na seção 3.4, configurando na nossa tabela de vizinhos com somente o GK
da Austrália conseguimos fazer com sucesso ligações para a Austrália. O mesmo
raciocinio foi usado para fazer ligações para os EUA, configurando como GK vizinho
somente o Internet2 GK, e discando para o telefone 1979... (Texas), a ligação funcionou
normalmente.
Agora quando colocamos os dois GK simultâneamente na nossa tabela de
vizinhos, estranhamente recebemos sempre uma resposta de confirmação do GK dos
EUA. A fig. 17 demonstra o fluxo de mensagens deste problema.
Na situação 1, o telefone ligado ao Cisco na UFRJ (GW) está fazendo uma
ligação para a Austrália. Estão configurados no GK UFRJ os dois GK (AARNET e
I2GK) como vizinhos. São enviadas mensagens de LRQ para todos os vizinhos, e
teoricamente, o GK que deveria responder com LCF seria o GK da Austrália. Mas,
recebemos duas respostas de Location Confirm (LCF). Como a implementação do
Opengate não distingue os LCF recebidos, o primeiro LCF que for recebido será
PBX
Telefone
GK DiretórioAARNET
GK DiretórioUniv. Indiana
Telefone
PBX
Internet2
GK UFRJ
GW Cisco 2600
I2GK=134.68.106.10AARNET=203.22.212.245
LRQLRQ
LCFLCF
Situação 1 -Discando para
Austrália
Situação 2 -Discando para
EUA
Fig. 17 – Problema de Location Request entre Sites VOIP da Internet2
62
repassado para o GW. Assim, isso sempre acontecerá, visto que o tempo de ida e volta
(Round-Trip Time -RTT) dos pacotes entre Brasil-EUA é bem menor do Brasil-
Australia, não importando a ordem em que os GK vizinhos estão na tabela do GK
UFRJ.
A resposta LCF vinda do Internet2 GK para um prefixo australiano (Cenário 1)
indicaria que este GK tem conectividade de telefonia IP com a Austrália, entretanto
quando o cliente tenta fazer a conexão com o número IP associado ao LCF, a ligação é
desconectada com o motivo prefixo não registrado (peerNotRegistered). Na situação 2,
quando ligamos para números telefônicos dos EUA, o Internet2 GK responde
afirmativamente e a ligação é completada com sucesso.
Fizemos um teste complementar, pois acreditavamos que isso era apenas um
problema de configuração do Internet2 GK. Apagamos a entrada deste GK de nossa
lista de vizinhos e repetimos as situações 1 e 2 somente com o GK Australia
configurado como vizinho. Na situação 1, ligando para prefixo australiano, a ligação
aconteceu perfeitamente. Mas na situação 2 se a ligação tiver prefixo dos EUA, o GK
Australia também responde afirmativamente, e depois desconecta a ligação com a
mensagem prefixo não registrado (peerNotRegistered). Como os dois GK destes sites
usam o software DGK podemos concluir que o problema esteja relacionado a esta
arquitetura proprietária, mas sem conhecer os logs das ligações destas instituições não é
possível fazer maiores afirmações.
Em fevereiro de 2002, o grupo VOIP da Internet2 começou a estruturar uma
solução mais centralizada para a realização de ligações entre GKs. De modo que as
zonas remotas pudessem configurar como vizinho apenas um GK central (o GK
Internet2). A implementação desta característica está mostrada na Fig. 18.
Em testes realizados com este Internet2 DGK central, fizemos ligações para a
Austrália (Camberra) obtendo como resposta um LCF com o endereço de outro GK dos
EUA, novamente o mesmo erro encontrado nos outros testes. Acreditamos que como os
padrões da ITU-T prevêm que a sinalização H.323 poderia, usando o modo GK Routed,
ser cascateada por uma nuvem de GKs, e esta operação é extremamente onerosa para a
rede. Algumas implementações como o DGK da Cisco [18] podem ser conservadoras
em comunicações multihop entre mais de 3 GKs envolvidos na chamada.
63
Telefone
UFRJ GK
Internet2 DGK
AARNET DGK
Camberra GK
PBXTelefone
Fig. 18 – Configuração do Grupo VOIP Internet2
Pois se cada GK enviasse LRQ/LCF para todos os seu vizinhos e
continuássemos propagando estas mensagens, poderíamos sofrer de uma inundação de
mensagens de localização.
No caso da implementação do Opengate, não é possível fazer a operação
multihop entre três GKs. Fizemos este teste de comprovação, configurando 3 GKs em
redes distintas da UFRJ, um no IP 146.164.247.202, outro no IP 146.164.8.193, e o
último no IP 146.164.251.49. Registramos os usuários cesar e vitor, respectivamente
nos GKs 247.202 e 251.49. Configuramos o GK central 8.193 colocando nele como
vizinhos os outros dois GKs e cada um dos GKs das extremidades como sendo vizinho
do GK central. Em procedimento de localização (LRQ) de usuário cesar, partindo-se do
GK 251.49, o pedido de LRQ cesar foi recebido pelo GK central 8.195, que
simplesmente respondeu Location Reject (LRJ) sem continuar a pesquisa para o GK
247.202.
A ITU-T está trabalhando com estes problemas de escalabilidade do sistema de
localização, sendo uma área em estudo. Na versão 3 da recomendação H.323, por
exemplo, foi inserido o campo hopCount nas mensagens de localização LRQ para
diminuir a abrangência da inundação. Outra solução para o problema seria pela adoção
do Anexo G da recomendação H.225, que trata das comunicações entre domínios
administrativos. Neste anexo é introduzido o elemento de rede chamado Border Element
cuja funcionalidade é trocar informações de endereçamento, de modo que cada domínio
64
administrativo possa resolver os endereços sem passar por um GK central. Usando estas
informações adicionais providas pelo Border Element seria possível ao domínio
administrativo determinar a rota mais apropriada para uma ligação.
Vimos na seção 3.1 que a recomendação H.323 na sua versão 4 aumenta a
confiabilidade do sistema de telefonia IP, ao utilizar um novo campo chamado
AlternateGatekeeper na sinalização RAS/H.225. Indicando endereços de outros GKs,
caso aconteça uma falha com um deles, de modo que o sistema continue operacional do
ponto de vista dos GWs. Desenvolvemos um esquema semelhante sem o uso deste
campo, usando somente a capacidade multicast da rede da UFRJ. Configuramos dois
GKs com a mesma identificação (GKID) e tabela de vizinhos, em duas redes com
conectividade multicast com o GW Cisco 2600. Modificamos a linha de configuração
do GW Cisco h323-gateway voip id UFRJGK 146.164.247.202 1719 para h323-
gateway voip id UFRJGK multicast. Nestes testes, se um dos GKs falhar, o GW
automaticamente realiza um novo GRQ (Gatekeeper Request) enviando esta requisição
via multicast, e sendo respondido pelo outro GK em funcionamento mantendo a
capacidade de realizar chamadas do sistema.
Para as ligações vindas da Internet para os GKs, seria possível configurar um
único nome no servidor DNS (gk.voip.nce.ufrj.br) associado a dois endereços IP para
manter a confiabilidade.
O uso de multicast auxilia numa forma de crescimento simples da rede H.323,
sem precisar reconfigurar cada gateway ou terminal. Além da possibilidade de realizar
pesquisas mais rápidas e sem inundação para certo escopo multicast.
Atualmente, o Cisco 2600 possui as capacidades de segurança previstas na
especificação H.235, onde todas as mensagens RAS enviadas na comunicação GW-GK
poderiam incluir o campo cryptoToken, prenchido com a informação de autenticação
obtida durante o GRQ/GCF, para validar a fonte da chamada. Por enquanto, nosso GK
3.5.1 – Considerações sobre a Confiabilidade e Escalabilidade do Ambiente VOIP H.323 da UFRJ
3.5.2 – Considerações sobre a Segurança do Ambiente VOIP H.323 da UFRJ
65
(opengate) não possui estas mesmas funcionalidades. Qualquer usuário com um
terminal H.323 e conhecendo previamente o endereço IP do GK poderia realizar
ligações, sem ter sua ligação autenticada, mas ela fica logada neste servidor.
De modo a aumentar a segurança do sistema adotamos algumas medidas, pelo
uso do IOS Access Control List (ACL) [58]. O ACL é uma lista de regras de filtragem
de pacotes colocadas no roteador. Assim, colocamos uma regra para aceitar mensagens
de sinalização H.225 vindas somente de nossos GKs (liberando a porta 1720 para eles).
E outra regra para liberar os fluxos de mídia (faixa de portas UDP de 512 até 65535) de
todos os usuários potenciais, negando o uso da porta 1720 de sinalização H.225 destes
usuários. Entende-se por usuário potencial, por enquanto, como qualquer usuário H.323
da Internet, mas podemos otimizar este filtro (pelo uso de ACL) para receber mídia
apenas de certos IP, como um sub-conjunto de GWs.
Para este sistema de segurança operar corretamente é preciso que o GK seja o
redirecionador de toda a sinalização H.225, de modo que a negociação das portas de
comunicação seja feita via GK, e que só então os fluxos UDP trafeguem para o GW sem
maiores problemas, bloqueando as tentativas de chamadass.
66
CAPÍTULO 4
PROGRAMAÇÃO DE SERVIÇOS DE TELEFONIA IP
Este capítulo está organizado em cinco seções. Na seção 4.1, descrevemos como
são feitos os serviços avançados de telefonia na arquitetura H.323. Na seção 4.2,
detalharemos um pouco mais sobre a linguagem CPL, suas estruturas de linguagem
(tags), e um exemplo de sua utilização para rotear chamada baseado na hora do dia. A
implementação da ferramenta de geração de scripts CPL, a partir de uma representação
gráfica é mostrada na seção 4.3. Na seção 4.4, discutimos as opções de implementação
do servidor gatekeeper com extensões CPL e mostramos o exemplo do funcionamento
deste servidor. Considerações sobre a escalabilidade da solução são apresentadas na
seção 4.5.
4.1 – Serviços Avançados H.323 de Telefonia IP
Temos duas abordagens para a programação de serviços telefônicos num
ambiente formado por terminais, gateways e servidores de registro H.323: a primeira
padronizada pela ITU-T, chamada de serviços suplementares, e a segunda baseada na
reprogramação do servidor H.323 (Anexo O H.323 ainda em estudo pela ITU-T).
Os serviços suplementares descritos nos padrões H.450.X (ITU-T, 1997) são
executados através de uma seqüência bem particular de mensagens H.255 [52] do tipo
Facility trocadas entre dois terminais. Esta comunicação é caracterizada pelo pedido de
um terminal em relação ao outro para que seja executado algum procedimento no
terminal remoto. Estas mensagens Facility podem transportar informações sobre qual
roteamento que a sinalização deve seguir ou a ativação de algum programa externo.
67
Cada mensagem H.225 Facility que ativa um serviço suplementar deve
transportar as chamadas APDUs (Application PDUs), onde ficam os parâmetros de
redirecionamento. Estas mensagens devem ser codificadas, decodificadas e
interpretadas pela máquina remota. Para cada tipo de APDU a ITU-T tem formalizado o
processo de criação, configuração e execução deste serviço suplementar. Esta
formalização vai desde a especificação da gramática ASN.1 da mensagem contendo o
serviço, até o procedimento exato de como isto deve ser processado, descrito por
diagramas formais da ITU-T chamados SDLs (Specification and Description Language
Diagrams).
Nos últimos anos, a ITU-T vem padronizando muitos destes serviços
suplementares, contando atualmente com onze novos documentos H.450 (do H.450.1
até H.450.12), atendendo a uma demanda crescente da comunidade de telefonia IP pela
programação de serviços. Também foi padronizada uma especificação para a criação
genérica de serviços suplementares [59] para que extensões livres pudessem ser criadas.
.
Call TransferFacility Setup to C
A (em conversação) B (em conversação)
C (Desligado)
A (Transferindo) B (Gateway da Chamada)
C (Transferido)
A (Desligado) B (em conversação)
C (em conversação)
Call TransferFacility to C
Call TransferSetup to C
ANTES DOCALL TRANSFER
APÓS O CALLTRANSFER
(A) Serviço Suplementar Call Transfer
(B) Implementação de Call Transfer no OpenPhone
Fig. 19 – (A) Serviço Suplementar Call Transfer e (B) Implementação de Call Transfer no OpenPhone
Entre os exemplos mais comuns de serviços suplementares, temos o H.450.2
Call Transfer Supplementary Service [60]. Este serviço permite que um usuário (usuário
68
A ou iniciador da transferência) transforme uma chamada existente com o usuário B
(sua chamada primária) em uma nova chamada entre o usuários B e um outro usuário C
(usuário transferido), selecionado pelo usuário A (Fig. 19-A)
O terminal openphone (Fig. 19-B), diferentemente do Netmeeting, implementa
alguns destes serviços suplementares. Logo que a ligação de telefonia IP se completar
ficam habilitados dois botões (Fig. 19) para acionar estes serviços: os botões de
Transfer, e o de Hold (a direita). O botão Call Transfer aciona o serviço descrito na Fig.
19-A. Nesta implementação também pode ser configurado como será o transporte da
APDU via Facility (visto anteriormente) ou canal lógico H.245, sendo esta outra
abordagem para iniciar o serviço.
O SIP, por sua vez, também tem a sua especificação genérica para a criação de
serviços avançados [61], mas o mapeamento entre os serviços suplementares H.323 e
estes serviços avançados SIP não é uma boa prática para convergir num ambiente
heterogêneo de telefonia IP. Porque estes padrões são muito diferentes.
O Quadro 13 abaixo ilustra os serviços suplementares H.323 e sua descrição:
Serviço Suplementar Descrição Call Transfer
Supplementary Service (H.450.2)
Explicado no texto.
Call Diversion Supplementary Service
(H.450.3)
Permite que, durante a fase de estabelecimento de chamada, seja desviada de uma chamada para outro terminal de destino.
Call Hold Supplementary Service (H. 450.4)
Permite que o Usuário A coloque o Usuário B (com quem tem uma ligação ativa) em uma condição de espera. Durante esta condição, deve ser provido música ou video para este usuário. E o usuário A pode realizar outras transações enquanto B estiver esperando.
Call Park and Call Pickup Supplementary Services
(H.450.5)
Permite que um usuário A ao realizar a chamada com o usuário B, permaneça estacionado enquanto aguarda numa fila de espera para ser atendido por B.
Call Waiting Supplementary Service
(H.450.6)
Permite que um usuário enquanto estiver em estado de ocupado seja informado das novas ligações que estão chegando com uma indicação. Este usuário pode optar por aceitar, rejeitar e ignorar esta nova ligação.
Message Waiting Indication Supplementary
Service (H.450.7)
Permite ao usuário enviar uma mensagem de indicação de Espera. Outros usuários podem verificar em uma Central de Mensagens por estas Indicações de Espera.
Name Identification Supplementary Service
(H.450.8)
Permite que o usuário chamado veja o nome ou identificação do usuário chamador.
Call Completion Supplementary Services
(H.450.9)
Permite que um usuário A chamador ao encontrar um destino ocupado usuário B, tente automaticamente completar a chamada mais tarde, quando o usuário B não estiver mais ocupado, sem precisar realizar uma nova tentativa de ligação.
69
Call Offer Supplementary Service (H.450.10)
Permite na requisição do usuário chamador que seja ofertado um tom de discagem para o usuário chamado quando ele estiver ocupado.
Call Intrusion Supplementary Service
(H.450.11)
Permite que o usuário chamador ao estabelecer a comunicação com o usuário chamado quebre uma comunicação já estabelecida entre este usuário chamado e um terceiro usuário.
Quadro 13 – Tabela de Serviços Suplementares H.323
A outra abordagem de construção de serviços para ambiente H.323 (Anexo O do
H.323) seria pela própria reprogramação do gatekeeper, o que exigiria do administrador
um conhecimento abrangente do funcionamento do H.323 e da API de programação
associada ao GK. Um exemplo deste tipo de reprogramação do servidor seria a criação
de um serviço de cobrança (billing), onde, toda vez que a sinalização Q.931 fosse
utilizada, seria logado o tempo de início e fim da chamada. Esse tipo de reprogramação
no servidor é bastante específico, e totalmente dependente da API do GK sendo
utilizada.
Outro modelo de programação de serviços seria pelo uso da programação CGI
em conjunto com o servidor gatekeeper, ou o modelo usando CPL, seguindo os
preceitos de Programação de Serviços de Telefonia Internet descritos por Rosenberg em
[19].
O CPL (Call Processing Language) descrito como uma forma de controlar
serviços de telefonia IP, não está teoricamente associado a nenhuma arquitetura de
sinalização, apesar da recomendação CPL prover muitos exemplos usando o SIP.
Existem algumas implementação de servidores com extensões CPL como o Servidor
SIP da Universidade de Columbia [23], mas para o ambiente H.323 está área ainda está
em estudo, com poucos protótipos.
Optamos pela abordagem de programação de serviços usando um servidor GK
com CPL (seção 4.4), de forma que não seja necessário reprogramar toda vez a API do
GK. Os serviços criados pela CPL tem uma variedade muito maior do que os serviços
suplementares criados no H.323. Seria possível inclusive com o CPL mapear alguns
deste, por exemplo, os serviços acionados na fase de estabelecimento de chamada como
o H.450.3, H.450.6, H.450.9. Os outros serviços suplementares H.323 dependem de
uma extensão para que o CPL atue de modo interativa e faça a reprogramação durante a
chamada.
70
4.2 – Definição da Linguagem de Processamento de Chamada (CPL)
Baseado em requisitos rígidos da criação de serviços CPL (pois eles vão ser
instalados pelos usuários, e seu funcionamento têm que ser garantido), a linguagem CPL
foi projetada como um grafo orientado acíclico de decisões e ações, que define como
será o tratamento para este serviço.
O uso de documentos XML [21] são perfeitos para a representação estruturada
de dados, particularmente de estruturas de árvores, a forma necessária para representar
estes grafos orientados acíclicos, que definem o tipo de programação de serviço. Por
isso, o CPL foi definido como um conjunto de marcações (tags) em XML. Uma
vantagem importante do uso de XML para representar esta programação de usuário é
que a semântica e sintaxe de um script pode ser verificada em tempo de execução. A
verificação é feita entre o documento criado e certos validadores XML chamados
Document Type Definitions (DTDs). Isso é crucial pelo fato de que todo serviço CPL
deveria estar coerente para poder garantir ao cliente que irá executar com sucesso.
Na CPL temos quatro grupos de primitivas (tags) básicas, que são:
Nós switch:
Representam as decisões que um script deve tomar podendo ser de 4 tipos.
Quando a decisão for baseada em endereços (URLs) de telefonia IP usa-se o nó
address-switch. Para decisões que são baseadas em outros parâmetros das
mensagens de sinalização (por ex. só quero aceitar ligações que vierem de
usuários usando o Netmeeting) usa-se o nó string-switch. Para decisões baseadas
em hora do dia temos o nó time-switch. O nó priority-switch é o que permite
tomar a decisão com relação a prioridade especificada na mensagem de
sinalização.
Nós location:
Os nós locations adicionam e removem localizações do usuário dono do script.
Existem 3 tipos de nós location: o nó location que adiciona a localização em
uma lista onde é possível encontrar o usuário; o nó lookup que passa como
referência em qual servidor de registro tal usuário pode ser encontrado; e o nó
remove- location para remover uma localização da lista.
71
Nós signalling operations:
Representam o núcleo da linguagem de programação de serviços, evocando os
procedimento de sinalização de chamada, atuando diretamente sobre o
comportamento dos servidores. Temos três tipos, o nó Redirect, que representa o
redirecionamento da chamada usando o modo “SIP Redirect” ou “GK Direct
Call Mode”. E o nó Proxy, que representa o redirecionamento da chamada
usando o modo “SIP Proxy” ou “GK Routed”. Também temos o nó Reject, que
representa a rejeição da chamada.
Nós non-signalling operations:
Permitem fazer ações com as chamadas, fora do contexto normal de um servidor
de telefonia IP, como enviar um email (nó mail) dizendo que certo usuário ligou,
ou logando as chamadas em arquivo no servidor para montar um serviço pré-
pago (nó log).
Nós incoming, outgoing e sub-action:
Os nós incoming e outgoing são os primeiros nós a serem executados, eles
indicam se o script vai ser executado quando a chamada estiver sendo
direcionada para o autor do script (incoming), ou partindo do autor (outgoing).
Já os nós sub-action representam, se estiverem no mesmo nível que o incoming e
outgoing, um sub-grafo como se fosse uma sub-rotina que pode ser referenciada
a partir do fluxo principal. E quando este nó aparecer dentro dos fluxos
<cpl> <incoming> <time-switch tzid="America/New_York" tzurl="http://zones.com/tz/America/New_York"> <time dtstart="20000703T090000" freq="weekly" byday="MO,TU,WE,TH,FR"> <lookup source="registration"> <success> <proxy /> </success> </lookup> </time> <otherwise> <location url="sip:[email protected]"> <proxy /> </location> </otherwise> </time-switch> </incoming> </cpl>
Quadro 14 – Exemplo de Script CPL de Roteamento pela Hora do Dia
72
incoming e outgoing estaremos apontando para a sub-rotina (sub-action) com o
mesmo nome.
O exemplo (Quadro 14), acima, foi extraído da recomendação CPL [20], e
mostra o uso dos tags de roteamento por regra de tempo. O tag <incoming> representa
uma chamada direcionada para o autor do script. A tag <time-switch> é uma tag
dependente do sistema (e não da sinalização) e representa uma decisão a ser tomada
com relação a hora local, esta tag esta configurada com os parâmetros de time-zone para
usar o horário de Nova Iorque. Cada tag do tipo switch têm sempre nós filhos que
representam as possíveis opções de escolha, no caso temos duas opções <time> e
<otherwise>. A opção <time> descreve um intervalo de tempo em que uma chamada IP
que estiver chegando será processada. Se ela chegar naquela hora prevista nas condições
será executado os nós filhos da decisão correta. Seria possível construir vários
intervalos de <time> para fazer um roteamento mais complexo por várias horas do dia.
O processamento do nó <lookup> é feito pelo servidor de telefonia que pesquisa
a localização atual de registro do usuário autor do script. Caso esta pesquisa obtenha
sucesso, tag <success>, então a chamada será roteada <proxy> para o autor do script
com o endereço encontrado no passo anterior. Por outro lado, quando a requisição
chegar fora do período de tempo estipulado pelo <time>, o processamento recairá sobre
o <otherwise> que, a partir de uma URL explícita descrita no tag <location>,
redirecionará a chamada <proxy> para aquele endereço, ou seja mandará a requisição
para o [email protected].
Apesar da recomendação CPL [20], descrever a linguagem de programação de
chamada como independente de protocolo de telefonia IP, neste documento quase todos
os exemplos descritos usam o protocolo SIP. A parte que explica como implementar nós
CPL para H.323 fica reservada ao Anexo B da Recomendação CPL.
A ITU-T também iniciou um estudo sobre a viabilidade da implementação do
CPL para sua pilha de protocolos através do documento Anexo O da Recomendação
H.323 [27], entretanto ambos os documentos apresentam certas divergências no
tratamento das tags. O próprio documento da recomendação CPL considera o uso
4.2.1 – Mapeamentos entre o comportamento da CPL de SIP para H.323
73
sugerido para H.323 como apenas normativo, e portanto sujeito a quaisquer normas a
serem criadas pela ITU.
Descrevemos algumas destas divergências, que enfocam como os nós CPL
atuam e sua relação com os campos de cabeçalhos dos protocolos, usando tanto a
abordagem do Apêndice B do CPL, quando do Anexo O do H.323 (Quadros 15 até 20).
Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nós Incoming e Outgoing
Indica se o script CPL será executado quando a chamada foi encaminha para o dono do script ou partindo do dono do script.
Segundo o Apêndice B do CPL não há diferença destes nós no ambiente SIP e H.323.
Quando o nó for incoming, se o nó address–switch estiver sendo utilizado, caso ele esteja com parâmetro destination, usar o H.323 destCallSignalAddress
Quadro 15 – Diferenças para os nós Incoming e Outgoing
Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nó Address-Switch
Decisões baseadas em endereços presentes na requisição original. Parâmetro field (origin,destination)
No H.323, o parâmetro origin corresponde ao H323 SourceAddress contendo vários alias addresses. Deve-se adotar uma política de prioridade, caso múltiplos aliases estiverem presentes.
Embora, mais do que um simples Alias possa existir em uma mensagem H.323. A opção obrigatória da escolha alias dentro de um número de possibilidade limita os sistemas H.323
Quadro 16 – Diferenças para os nós Address-Switch contendo parâmetro field Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nó Address-Switch
Decisões baseadas em endereços presentes na requisição original. Parâmetro subfield (alias-type)
O mapeamento dos endereços H.323 em sub-fields dependem do alias-type. Os possíveis valores de alias-type seriam: dialedDigits, h323-id, uri-id, transportID, emailID, partyNumber, mobileUIM e Q931IE.
Segundo o Anexo O, a seção “Address-Switch Mapping for H.323” da Especificação CPL deveria ser usada como “ilustração” de como os campos CPL poderiam ser mapeados em campos H.323. Entretanto, Anexo O não define este mapeamento.
Quadro 17 – Diferenças pra os nós Address-Switch contendo parâmetro sub-field Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nó Strin-Switch
Decisões baseadas em quaisquer informações textuais presentes na requisição da chamada. Parâmetro field: (subject, organization , user-agent, language e display)
No H.323, o nó string-switch com o parâmetro language poderia ser obtido pelo campo H.323 UUIE language, traduzindo-se o formato especifcado daquele campo. O campo CPL display corresponde ao campo display Q.931 de mesmo nome.
Nada é definido com relação a isso.
Quadro 18 – Diferenças para os nós String-Switch contendo parâmetro field
74
Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nó Location
Especificam localização a ser usada para o redirecionamento. Parâmetro url
Location no H.323 deve ser especificado como H.323 url-id. Também seria possível o uso de outros alias-types desde que tenhamos esta extensão CPL.
Se ativarmos sinalização “outband” através da CPL, alguns dados significativos de saída (resposta do CPL) podem não estar disponíveis nas URLs H.323, assim como estariam nas URLs SIP. Ex. Reject Reason.
Quadro 19 – Diferenças para os nós Location contendo parâmetro url Nó CPL Significado Apêndice B do CPL Anexo O do H.323 Nó Lookup
Especificam meios externos para buscar locations para o redirecionamento
Os nós de lookup, fazem uma busca dos registros correspondentes ao location que estejam registrados no servidor GK de uma Zona Administrativa usando mensagens RAS.
O nó lookup é um conceito independente de sinalização, mas no caso do SIP, o lookup pode ser feito com outros parâmetros de filtragem, por exemplo, por capacidades. O que não é suportado no H.323
Quadro 20 – Diferenças para os nós Lookup
Os outros nós CPL, como o time-switch, priority-switch, os nós específicos da
sinalização como redirect, proxy, reject e os nós mail e log não apresentam divergências
sobre o seu significado para o ambiente H.323. Esse estudo preliminar foi necessário
para tomarmos decisões de quais campos e mensagens tratar na execução de um script
CPL para o ambiente H.323.
No caso da divergência da interpretação, nós optamos por usar o Apêndice B da
CPL, por ter maior detalhamento de quais operações e campos devem ser checados do
que o Anexo O do H.323, considerado ainda muito incipiente na área de CPL.
4.3 – Implementação de Editor CPL
Para construir os scripts CPL-XML, desenvolvemos um editor com interface
gráfica, argumento defendido como um requisito básico do Framework CPL [24], para
que os usuários com pouca experiência em criar e editar scripts CPL (e
consequentemente com código XML), possam montar esquemas de como desejam que
o fluxo da chamada seja redirecionado de uma maneira gráfica, extremamente fácil e
prática. Dessa forma, estaremos ajudando no desenvolvimento de novos serviços de
programação com CPL e também contribuindo com a sua popularização.
Nossa implementação deste editor foi desenvolvida em Java usando a tecnologia
de applets com Java Plugin. A ferramenta se baseia na filosofia “What you see is what
75
you get”, onde o usuário não interage diretamente com as tags XML, e sim com botões
coloridos representando as tags e que podem ser conectados para formar o grafo do
serviço desejado em CPL. Esta filosofia é usada nas ferramentas de construção de
Website (como Dreamweaver da Macromedia), onde o programador web não precisa
entender as tags HTML para montar uma página. Ele faz todo o trabalho visualmente,
enquanto o programa monta as tags internamente.
Na Fig. 20 a seguir, temos uma amostra do programa, onde criamos o exemplo
“script complexo”, referenciado pela especificação CPL [20]. A tela de trabalho
apresenta cinco áreas, quatro delas com menus e uma área central onde são organizados
os botões que representam os nós XML.
Fig. 20 – Editor Gráfico de CPL e Gerador do XML correspondente ao grafo CPL
O menu superior (Incoming/Outgoing/SubAction) aciona o painel central (área
branca da tela). Este painel central está organizando internamente como uma pilha de
painéis (um painel para incoming, outro para outgoing, e N painéis para subactions).
Assim, o usuário pode criar um conjunto de nós e depositá- los em um painel central
76
(Incoming), depois acionar outro painel central (Outgoing) clicando no menu superior, e
inserir outro conjunto de nós independentemente daqueles do primeiro painel.
O menu à esquerda é o construtor de botões CPL, este menu está organizado por
cores agrupando conjuntos idênticos de nós (azul – nós location, rosa – nós signalling
operations, e verde – nós switches). Quando o usuário clica neste construtor, um novo
botão com o respectivo nome de nó (Location, Lookup ...) e cor é criado. Sendo
colocado no painel central que estiver em uso.
Cada novo nó criado (botão colocado no painel central) tem um menu de opções
próprio associado à direita com suas respectivas configurações. No exemplo da Fig 20,
o nó ativo é o Sub-action (em amarelo ), quando se clica sobre ele, automaticamente este
nó muda o menu de configuração (à direita). Neste caso podemos configurar o nome da
referência (ref) da SubAction para voicemail.
O menu inferior permite que sejam criadas/removidas linhas de conexão entre os
nós, orientadas por setas, através da opção Connect/Disconnect deste menu. E remoção
dos botões através da opção Remove. O último botão deste painel é o Generate, que
quando acionado, gera automaticamente o XML correspondente àquele CPL desenhado
pelo usuário.
Esta implementação tem duas visões para o mesmo grupo de objetos básicos: a
visão do gerenciamento da parte gráfica e o da manipulação equivalente em XML.
Usamos a biblioteca swing, do Java, no desenvolvimento da parte gráfica. E a biblioteca
xerces versão Java, do projeto Apache [26], para manipular e gerar documentos XML.
A parte gráfica do editor foi desenvolvida por outro membro do grupo do
laboratório VOIP, e realiza a organização dos painéis de controle, e os respectivos
botões com seus painéis de configuração. A Fig. 21 apresenta o diagrama de classes
deste módulo. A classe MainClass (Applet) gerencia a interface gráfica e mantém dois
vetores, um contendo os painéis da parte central do editor (vectorPanel), e o outro
contendo o vetor da classe Figuras (abstração de um conjunto de botões).
4.3.1 – Gerenciamento da Parte Gráfica do Editor CPL
77
Fig. 21– Diagrama de Classe da Parte Gráfica do
Editor CPL
Cada classe Figuras contém todos os botões que foram incorporados no
respectivo painel central, ela gerencia a montagem das linhas de conexão entre botões.
A classe botão é uma super-classe que tem herança da classe JButton do Swing (Java) e
cujos métodos todos os botões especializados herdam.
Cada painel central, armazenado no VectorPanel, tem o gerenciador de layout
configurado como null. Isso permite que os botões possam correr livremente sobre a tela
como se estivessem flutuando. Para controlar os limites da tela, a super classe botão
implementa o método verificaLimites( ), que, obtendo o tamanho das bordas do painel
central, não deixa a posição do botão passar estas bordas.
O programa também tem uma parte responsável pela criação de novos objetos
XML, criados a medida que o contexto gráfico for sendo atualizado. Utilizamos a
abordagem de implementação XML baseada no modelo DOM [21] (Document Object
4.3.2 – Gerenciamento da Parte de Manipulação XML
78
Model). Nesta abordagem, o documento todo é armazenado na memória e representado
por uma estrutura em árvore, essa abordagem é mais fácil de ser trabalhada devido ao
foco do programa do que a abordagem SAX que utiliza funções de retorno callbacks
para trabalhar com eventos nos nós CPL. O diagrama de classes da Fig. 22 ilustra a
organização do DOM no editor CPL.
Fig. 22 – Diagrama de Classe da Parte XML do
Editor CPL
A classe principal (MainClass) ao ser ativada, cria uma instância do gerenciador
DOMManager. Este gerenciador possui a implementação da interface Document do
modelo DOM do Xerces, nesta estrutura ficarão armazenados todos os objetos XML do
grafo, no caso os objetos Element de botão.
Cada nó ao ser ao ser criado, aciona o seu próprio método createXML, e cria
também uma instância do seu elemento XML (ex. AddressSwitchXML)
correspondente, preenchendo o nome da tag relacionada no nome do botão. Este
Element é adicionado ao DOMDocument principal da classe DOMManager, mas não é
feito neste passo nenhuma relação pai- filho entre estes elementos.
Toda vez que o usuário tenta conectar dois botões com uma seta, o primeiro
botão selecionado habilita o método conecta ( ) e o segundo botão faz uma chamada ao
79
método insertChild do DOMManager, passando como parâmetro os dois botões para
criar um relacionamento pai- filho, através de element_origem.AppendChild
(element_destino). Estes relacionamentos vão criando as ramificações da árvore CPL-
XML. E o método setParameters é acionado cada vez que o botão perde o foco, e
reconfigurado os atributos do XML, obtendo todas as informações de configuração do
menu à direita, com um painel associado a cada botão.
Quando o usuário clicar em Generate, o método GenerateXML (botão do menu
inferior) da classe DOMManager é acionado. Ele percorre o vectorFiguras, e em cada
um deles procura pelo botão incoming, outgoing ou subaction (que não podem ser
removidos) raízes destas sub-árvores para criarem um relacionamento raiz- folhas com o
elemento principal <cpl>, usando a chamada root.appendChild(incoming.node), por
exemplo, para inserir o sub-grafo do incoming no grafo principal. Depois serializa o
DOM para exibir o fluxo XML gerado identado em uma caixa de diálogo para o
usuário.
A parte de validação pode ser feita através da segmentação deste DOM
serializado via parser com parâmetro validate em true, antes dele ser exibido pela caixa
de diálogo. Se todo o processo ocorrer bem, então ele pode-se exibir o XML, senão na
caixa de diálogo são apresentados os erros que aconteceram, mensagens de erros padrão
da biblioteca Xerces.
Um aspecto que devemos ressaltar é que a entrada do DOMparser normalmente
é uma URL, ou arquivo, e no nosso caso, como estamos trabalhando com uma applet
com restrições de manipulação de arquivos, precisamos passar como parâmetro ao
parser, o fluxo em bytes serializado pelo DOM e encapsulá- lo no objeto InputSource( )
da biblioteca Xerces [26].
O passo seguinte é submeter o script CPL ao servidor H.323 com esta extensão,
para que seja instalado o serviço CPL de redirecionamento de chamada relacionado a
certo usuário. Modificamos um instalador (uploader) em Perl desenvolvido por [62],
com o suporte a autenticação de usuário via senhas criptografadas e a gravação de
4.3.3 – Utilizando Serviço Web para Gatekeeper
80
arquivo via envio de arquivos por HTTP Mime-type multipart-form (Fig.23), com este
objetivo.
Fig. 23 – Instalador CPL para Ambiente H.323
As mudanças no script Perl são para que o nome do arquivo a ser enviado para o
servidor Web seja modificado com o próprio nome de login do usuário mais a extensão
.cpl. Na parte do código onde o arquivo é gravado no servidor, fizemos uma alteração
para possibilitar a verificação via segmentação XML, observando se o documento
enviado está em conformidade com o DTD CPL (validando este documento XML) e
então permitir salvar o arquivo no diretório de trabalho do gatekeeper. Uma outra
maneira de implementar este instalador CPL baseado na Web, seria adicionar ao
gatekeeper um módulo de manipulação HTTP (como o já implementado no opengk).
A biblioteca Pwlib [10] já provê estes objetos (PHTTPService,
PHTTPNameSpace, PHTMLPage) e assim o próprio gatekeeper poderia montar uma
política de cadastramento de logins de usuários via interface web e procedimentos de
segurança H.235, dando maior segurança ao serviço CPL. Não implementamos esta
abordagem porque o transporte destes objetos do contexto do opengk para o contexto do
opengate (software que escolhemos para implantar na nossa rede H.323) não era trivial.
4.4 – Implementação de Gatekeeper com Extensão CPL
Optamos por desenvolver a extensão CPL no servidor Opengatekeeper [10],
principalmente, por ele trabalhar no modo GK Routed, que é necessário para o
tratamento de certos tags CPL de redirecionamento. Outro ponto favorável, foi a
81
experiência anterior de utilização dele na interoperação com a Internet2, conforme visto
no Capítulo 3.
A implementação está escrita em C++, com as bibliotecas do projeto OpenH323
[10] e a biblioteca Xerces do Projeto Apache [26] na sua versão para C++. O código
executa nos sistemas Windows e Linux. Descreveremos as opções de desenvolvimento
seguidas detalhando as alterações que fizemos no código do gatekeeper.
Todas as mensagens do protocolo H.225 RAS (Registration, Admission e
Status) são codificadas usando o padrão ASN.1 [63], diferentemente dos protocolos da
IETF que usam padrão textual para codificar suas mensagens. No padrão ASN.1 todos
os campos de protocolo das mensagens ficam escondidos sob uma máscara de bits,
sendo preciso usar um segmentador ASN.1 específico, para separar os campos. Como
uma das premissas do processamento CPL é a verificação do conteúdo dos campos do
protocolo, trabalhamos na segmentação destas mensagens H.225 RAS no servidor
gatekeeper. O diagrama de classes abaixo, mostra como é formada uma mensagem
H225_RasMessage no projeto Opengatekeeper.
Fig.24 – Diagrama de Classes das Mensagens RAS/H.225
Toda mensagem do protocolo RAS (ARQ, RRQ, LRQ, etc.) é encapsulada como
objeto, tendo herança na super-classe H225_RasMessage, de modo a delimitar o escopo
da mensagem. A classe H225_RasMessage por sua vez, herda de PASNChoice, que é
82
uma classe criada automaticamente por um gerador de parser para ASN.1 (codificador
do H.323). Na Fig. 24, temos o detalhamento da estrutura de uma mensagem
H225_AdmissionRequest. Ela é formada pela agregação de outras classes, como
H225_RequestSeqNum, H225_TransportAddress, H_225_ArrayOf_AliasAddress, que
representam os cabeçalhos de protocolo que formam a mensagem e que devem ser
checados.
Alguns campos têm vetor associado pois podem ter mais de um valor. Por
exemplo, o H_225_ArrayOf_AliasAddress (Fig. 24), presente nas requisições de
admissão tem um vetor associado a ele, contendo vários H225_AliasAddress. Neste
caso é preciso percorrer o vetor e verificar os tipos de alias que estão configurados. Os
mais comuns são os alias: url-id, email-id, e h323-id.
Toda vez que vamos usar um campo de protocolo, temos sempre que verificar
através do método HasOptionalField, se ele está presente naquela mensagem, visto que
certas implementações podem simplesmente deixar em branco o espaço reservado para
alguns campos (Quadro 21).
// Checagem do campo GatekeeperID do RRQ, se a msg. é realmente destinada a este GK const H225_RegistrationRequest & RegReq; if ( ( RegReq.HasOptionalField( H225_RegistrationRequest::e_gatekeeperIdentifier ) ) && ( RegReq.m_gatekeeperIdentifier != GKId )) {
PSYSTEMLOG( Info, "RRQ: They asked for a different gatekeeper" ); return DoRRJ( RegReq, Reply, H225_RegistrationRejectReason::e_undefinedReason, GKId );
} Quadro 21 – Trecho do Código de verificação se o GatekeeperIdentifier tem o mesmo ID do GK
Para que o serviço CPL comece a funcionar, é preciso que o usuário esteja ativo,
ou registrado. Para associar um script CPL ao usuário foi modificado o método OnRRQ
da classe RasServer. Este método é acionado toda vez que chega ao servidor uma
mensagem de RRQ (Registration Request).
O servidor Opengatekeeper armazena em uma base de dados organizada na
memória todos os registros já realizados, esta base de dados é chamada de
EndpointTabl. Adicionamos métodos à EndpointTabl para configurar em cada Endpoint
(abstração do terminal H.323 registrado) um campo chamado hasCPL. O valor de
hasCPL é sempre mantido em falso, a não ser que durante o processamento de OnRRQ,
83
o GK verifique que existe um arquivo com o nome <h323-id>.cpl no diretório de
trabalho. Este valor <h323- id> é extraído da mensagem do RRQ, neste caso o serviço
CPL pode ser configurado para este usuário (com este h323-id).
Esse módulo foi baseado na implementação em Java do parser CPL [64]. Ele é
formado por quatro classes que foram desenvolvidas em C++ (Fig. 25). A classe
CPLScript representa o script como um todo e é onde se realiza o parsing do arquivo
CPL; a classe CPLElement representa a investigação de cada elemento (tag) do
documento CPL; a classe CPLOperation aciona as sinalizações (das classes de
sinalização do GK, como a RASThread e a CallThread) fazendo o redirecionamento das
chamadas do GK, e por fim, a classe CallState mantém as estruturas de dados relativas
ao estado da ligação sendo processada, armazenando os cabeçalhos a serem verificados.
O GK pode, dependendo da fase da sinalização (durante o RAS, ou já na
negociação Q.931), acionar o CPLScript. Atualmente, estamos processando somente o
redirecionamento das mensagens vindas do protocolo RAS.
4.4.1 – Módulo de Manipulação CPL-XML do Servidor
Fig. 25 – Diagrama de Classes do GK com Extensão CPL
84
Cada vez que uma mensagem ARQ chega, o método OnARQ da classe
RasServer é processado. Este método verifica se o usuário sendo chamado possui script
CPL para ser executado. Optamos por primeiro processar os scripts que contenham a
sub-árvore Incoming. Para isso, ele faz acesso a tabela de Endpoints (EndpointTabl),
procura pelo Alias do usuário chamado, e ao encontrá-lo verifica se o campo hasCPL
está com o valor verdadeiro. (Esta variável estará verdadeira se o usuário estiver
registrado, e possuir o arquivo CPL no diretório de trabalho do servidor).Caso o valor
de hasCPL esteja verdadeiro, então é instanciado um objeto para CPLScript e
configurado os atributos do objeto CallState. O passo seguinte é segmentar o arquivo
CPL associado aquele usuário, e começar a executar a árvore de incoming, Novamente
estamos utilizando a abordagem DOM em detrimento da SAX, na manipulação do
XML, pois esta armazena toda a árvore de objetos na memória tornando mais rápido o
seu acesso.
Cada elemento CPL obtido é então escalonado para execução na classe
CPLElement, e são feitas as checagens entre os campos de protocolo e os tags CPL para
tomar as decisões.
Quando aparecerem após os nós de decisão, os nós CPL de manipulação da
sinalização (como por exemplo, nó CPL redirect), estes nós acionam os métodos da
classe CPLOperation doRedirect, que por sua vez está manipulando diretamente o GK
via RasServer, mandando como parâmetro uma mensagem H225_RasMessage
modificada, com o endereço a ser redirecionado.
Na nossa implementação, optamos por não usar a recomendação “alias-type”
para definir qual tipo alias será usado. Isto simplifica a lógica do programa, por estamos
trabalhando apenas com o alias h323-id.
Para entender como um fluxo H.323 é roteado por um script CPL, imaginemos o
cenário onde o usuário com alias h323-id cesar deseja realizar um tipo de
redirecionamento pela filtragem por endereço h323-id das ligações que estão vindo de
outros usuários. Primeiramente, ele gostaria de deixar que as ligações que viessem do
alias h323-id vitor fossem repassadas diretamente para o terminal onde ele está logado
(tendo absoluta prioridade). Mas, se a ligação vier do alias h323-id melman, ele gostaria
4.4.2 – Exemplo da Execução de Script CPL pelo Servidor
85
que a chamada fosse rejeitada (nenhuma prioridade) e todas as outras ligações seriam
redirecionadas para um serviço de voicemail.
Este serviço pode ser
reproduzido pelo seguinte script
CPL-XML mostrado na Quadro 22.
O tag <?xml version=“1.0” ?> diz
respeito à versão do XML usada. Em
seguida <!DOCTYPE ...> define
qual DTD é usado para validar a
estrutura deste script, no caso o DTD
do CPL fica armazenado no mesmo
diretório do servidor. O script inicia
com o tag <cpl>, sendo esta o nó raiz
da árvore de decisões. Tudo que
estiver entre <cpl> e </cpl> estará
associado a esta raiz.
Temos um grande bloco
<incoming>, indicando que todas as chamadas que vierem para o alias h323-id cesar
serão processadas. Abaixo do nó incoming, temos o nó <address-switch> indicando que
o script terá que tomar uma decisão baseada nos cabeçalhos de endereçamento. Os
parâmetros “origin” e “user” indicam o cabeçalho a ser checado frente as informações
do script é alias h323-id do chamador, extraído da mensagem de requisição.
São três as possíveis opções de redirecionamento da chamada:
<address is = “vitor”>
Se o usuário chamador tiver h323-id “vitor” então a chamada deverá ser
redirecionada (via modo direto, <redirect>) para o endereço padrão de cesar,
pois não foi especificada neste opção nenhuma outra localização.
<address is “melman”>
Se o usuário chamador tiver h323-id “melman” a chamada deve ser rejeitada.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE cpl PUBLIC "-//IETF//DTD RFCxxxx CPL 1.0//EN" "cpl.dtd"> <cpl> <incoming> <address-switch field="origin" subfield="user"> <address is="vitor"> <redirect/> </address> <address is="melman"> <reject/> </address> <otherwise> <location url="voicemail"> <redirect/> </location> </otherwise> </address-switch> </incoming> </cpl>
Quadro 22 – CPL/XML de Serviço de Redirecionamento por Endereço
86
<otherwise>
Em todos os outros casos de h323- id diferentes a chamada deve ser direcionada
para um programa de voicemail, configurado com o h323-id voicemail em
<location>.
O exemplo do fluxo de sinalização para o redirecionamento da chamada é
apresentado na Fig. 26. Nele, o usuário com o h323-id aguiar tenta entrar em contato
com o usuário cesar. Mas devido ao processamento do script acaba sendo redirecionado
para o voicemail.
Terminal H.323aguiar
Server
Terminal H.323cesar
ARQdestinationInfo
cesar
submetendocesar.cpl numaetapa anterior
<cpl><incoming>
cesar.cpl
CPLElement.next( )
<address-switch ...>... <otherwise> </location url="voicemail> <redirect>
RasServer.doACF
(voicemail)
ACFdestCallSignalAddress
IP do voicemail
RTP/UDP FLOW
GatekeeperCPL-Aware
OpenH323 AnsweringMachine
voicemail
SETUP
SETUP
ARQ
ACFaguiar não temscript associado
CONNECT
Fig. 26 – Fluxo Básico do Redirecionamento por Endereço (h323-id)
No estado inicial, os usuários aguiar, cesar e voicemail estão registrados no GK
com extensão CPL. cesar submeteu, durante o processo de registro, o serviço descrito
no Quadro 22. O fluxo começa quando aguiar faz uma chamada à cesar. Para isso, ele
requisita ao servidor a admissão da chamada via ARQ. No ARQ, o terminal preenche a
87
informação destinationInfo, contendo o alias h323-id cesar. O servidor recebe esta
mensagem, carrega o serviço CPL associado a cesar (cesar.cpl), e começa a processar
os nós.
No processamento deste script, ele tem que tomar uma decisão baseada no
endereço h323-id (Address-switch field=”origin” subfield=”user”). As opções
<address is> são checadas contra o cabeçalho srcInfo da requisição ARQ, pois é neste
campo que está preenchido com o endereço h323- id aguiar, logo a única opção válida
de roteamento do CPL é otherwise. A opção otherwise adiciona uma localização
alternativa para enviar a chamada. Depois usando o objeto RasServer aciona o método
doACF, com o parâmetro da mensagem de resposta, modificada no campo de cabeçalho
(destCallSignalAddress) contendo o endereço de sinalização associado ao voicemail. E
assim, a chamada segue seu fluxo normal entre aguiar e o voicemail.
Este servidor não tem suporte para todos os nós CPL possíveis. No momento,
estamos usando um sub-conjunto do DTD CPL para validar apenas os scripts cujos nós
estão implementados. Futuramente, pretendemos trabalhar com outras tags, como as de
Time-Switch, que precisam decidir o roteamento da ligação pela hora do dia. Lennox
[65] já desenvolveu um software em Java chamado Cal-Code para auxiliar na
determinação de períodos de tempo. Também pretendemos trabalhar com o tag
<proxy>, que requer uma grande mudança da estrutura do servidor, pois ele é acionado
após a chamada ter sido redirecionada.
O uso de serviços CPL com o servidor GK H.323 traz sérias conseqüências ao
desempenho do servidor. Quanto mais processamento tem que ser feito para concluir a
chamada, ou seja, quanto maior o número de nós de decisão do script, menor será a
escalabilidade do servidor. Por isso, o uso desta programação de serviços para o
ambiente H.323 deve ser mantido em servidores com abrangência departamental. Para o
núcleo da rede convém utilizar gatekeeper com menor inteligência em termos de
serviços, mas maior capacidade de roteamento das chamadas (o uso do modo Call
Direct, ajuda a aumentar esta capacidade, pois não é necessário manter o estado de cada
4.4.3 – Impacto do CPL para a Escalabilidade do GK
88
ligação nem rotear os canais de sinalização H.225). Este tipo de GK seria mais
adequados para fazer o peering dos gatekeepers departamentais.
89
CAPÍTULO 5
CONCLUSÕES E TRABALHOS FUTUROS
Este trabalho apresenta a implantação de um ambiente heterogêneo de telefonia
IP baseado em SIP e H.323 e implementações de um cliente SIP baseado em applet e
um framework de serviço de programação de chamada para H.323.
No capítulo 1, onde é feito o levantamento bibliográfico e das motivação deste
trabalho, mostramos como a idéia do núcleo básico dos protocolos de sinalização pode
ser utilizado para a construção de gateways como o SIP/H.323 GW. Também
apresentamos quais as mais importantes tendências atuais para a programação de
serviços de telefonia de uma maneira livre de plataforma como o JAIN e o DFC.
Quanto ao problema de feature interaction. Futuramente, será preciso
especificar um protocolo de comunicação entre as extensões CPL, reutilizando o próprio
BSM para poder identificar interações cooperativas e adversárias.
No ambiente SIP, visto no capítulo 2, descrevemos a implementação de um
serviço Web-to-Dial, baseado em tecnologia Java Applets, tendo como características
importantes a robustez no tratamento de mensagens de sinalização, a interoperabilidade
com a arquitetura SIP e a qualidade da captura, recepção e transmissão de mídia.
Este programa é constituído de seis módulos, no decorrer do projeto houve a
preocupação em se usar as melhores práticas de programação Java. Para solucionar o
problema de segurança no acesso aos recursos locais de rede e I/O, optou-se pelo uso de
auto-certificados. O módulo de transmissão e recepção de mídia via RTP/UDP usa a
biblioteca de manipulação de mídia Java Media Framework na versão 2.1.1, que oferece
um componente gráfico para exibição de estatísticas do RTCP e monitoração da
qualidade de serviço. O transporte da sinalização foi implementada de modo a permitir
90
que a sinalização ocorra tanto sobre UDP como sobre TCP, indistintamente. Para a
montagem de mensagens SIP foi utilizada uma codificação própria baseada em vetor,
que permite até mesmo o uso de compactação de cabeçalhos.
Na segmentação das mensagens (parsing) intermediárias, optou-se pelo uso da
biblioteca desenvolvida pelo NIST e que faz parte do módulo SIP-JAIN. Esta biblioteca
propicia uma forma mais robusta e flexível de tratamento de mensagens SIP, pois está
baseada na gramática ABNF e opera corretamente frente a cabeçalhos alterados e/ou
inexistentes.
O desempenho da segmentação das mensagens é avaliado e justificada a nossa
opção de usar um montador próprio para as mensagens iniciais, do tipo INVITE e
REGISTER, enquanto mensagens intermediárias são montadas usando o montador
NIST-SIP.
Na captura de mídia pelo browser, nossa opção foi pelo uso da API JMF em
oposição a Java Sound, pelos mecanismos de transmissão RTP e facilidade de
conversão de codificadores/ decodificadores presentes no JMF.
Em testes de interoperabilidade com outros clientes e servidores SIP, nosso
cliente mostrou resultado satisfatório aos vários cenários. Os resultados mostram que
algumas implementações SIP apresentam deficiências. No final do capítulo 2 é
apresentado a implantação do ambiente SIP, a escolha do servidor, questões de
escalabilidade, segurança e a interoperação com um gateway de telefonia convencional.
No aspecto de captura de áudio falta avaliar se a solução com uso da
javax.sound.* comparativamente com o JMF, tem desempenho suficiente para
integração com a telefonia convencional. Como extensão futura deste cliente SIP, temos
intenção de desenvolver um ambiente de gerência de VOIP que usaria o applet remoto
para recolher estatísticas da máquina do cliente e enviá- las para um servidor central,
armazenando estas segundo os padrões RTP MIB.
No capítulo 3, mostramos a implantação do ambiente de telefonia H.323. Neste
trabalho tivemos que nos atualizar com relação ao estado da arte das padronizações da
ITU-T observando as melhorias do protocolo. Estudamos três implementações de
Gatekeeper para optar pela implantação de um deles no laboratório, este estudo ajudou a
documentar o projeto OpenH323, visto que este possuí pouco material de introdução e
de exemplos sobre a programação de sua API.
91
Com o uso dos programas do projeto OpenH323 montamos uma metodologia de
testes para encontrar a origem de problemas na comunicação H.323. E organizamos a
estrutura de telefonia IP com o programa servidor escolhido Opengatekeeper. Como
trabalho futuro, queremos desenvolver um analisador de log para efetuar a
contabilização das durações das chamadas de telefonia IP, e estabelecer de acordo com
o nível de serviço, alguma processo de cobrança.
Mostramos os detalhes da implantação de um roteador com capacidade de
interoperar rede Internet com rede telefonica, sendo este utilizado como ponto de
entrada para o Brasil da arquitetura de telefonia IP da Internet2.
Na falta de um GK baseado no roteador Cisco, como presente em outras
instituições, demonstramos como anunciar números telefônicos através do GK em
software Opengate, sendo esta uma solução viável para este tipo de situação.
Os testes realizados com outros sites da Internet2 são discutidos, incluíndo a
discussão sobre os problemas de escalabilidade da requisição de localização no
ambiente H.323, e soluções para aumentar a escalabilidade, confiabilidade e segurança.
Como trabalho futuro, pretendemos desenvolver extensões no nosso GK (opengate)
para ele operar com busca multihop de uma forma eficiente. E para aumentar a
escalabilidade pretendemos trabalhar com multicast no nosso GK, visto que ele não
suporta a busca via multicast atualmente. Na questão de segurança pretendemos incluir
os objetos de manipulação H.235 da biblioteca OpenH323 para autenticar e criptografar
as chamadas antes destas alcançarem o gateway.
Para uma maior divulgação do projeto, pretendemos utilizar de uma linha tie-
line, com capacidade de coletar números, para que os usuários da UFRJ discando um
número especial tenham acesso, transparentemente, à telefonia IP, e por conseguinte,
numa maior interação entre pesquisadores da UFRJ e de diversas universidades do
exterior a um custo baixo e uma boa qualidade.
A parte final da dissertação, o capítulo 4, trata especificamente da questão dos
serviços de programação de chamada. Estes tem tido uma demanda grande por parte da
comunidade internacional. Muitas arquiteturas tem sido propostas e implementadas para
o ambiente heterogêneo de telefonia. Sabemos que a programação de serviços pode ser
implementada tanto no nível de comunicação entre clientes, como através de uma lógica
92
especial no servidor ou com o uso de componentes de software cooperando
mutuamente.
Com base em nossa experiência de construção de gateway H.323/SIP, podemos
afirmar que a implementação de gateways suportando a sinalização complexa requerida
pelas soluções de framework de serviços para ambiente VOIP heterogêneos, como
sugerida pelas propostas da Parlay/Jain e DFC/Eclipse, é extremamente dificil.
Apresentamos uma abordagem diferente destas propostas, fazendo uso de uma
linguagem de programação de chamadas bastante simple e genérica chamada CPL.
Desenvolvemos um framework, descrito no capítulo 4, para suportar este novo
tipo de programação de chamadas. Este framework é composto de um editor gráfico,
baseado em applet que edita scripts CPL e gera automaticamente o arquivo XML
correspondente a um serviço; um instalador de CPL para H.323 baseado em HTTP, pois
o ambiente H.323 não suporta mime-types. Por último, temos a implementação da
extensão CPL no servidor Opengatekeeper, esta implementação escrita em C++ faz uso
da biblioteca Xerces para segmentar e tratar os scripts CPL e checar os campos versus
cabeçalhos e executar os comandos do mesmo. Um exemplo do roteamento da chamada
pelo uso do script CPL é mostrado.
O impacto da utilização do CPL deverá ser medido em testes para avaliação de
desempenho em breve, para dizer o fator de redução da capacidade de roteamento que o
GK perde ao usar a abordagem CPL.
A questão da validação do script em tempo de execução pelo editor CPL, para
evitar que o usuário escreva um script inconsistente com o DTD CPL, terá que ser
aprofundada. Uma validação baseada na manipulação do XML é uma abordagem mais
interessante do que prover esta validação pelo software, pois caso fossem incorporado
outros nós ao CPL, parte do código desta validação teria que ser refeito. O servidor
H.323 com extensão CPL não dispõe de todas as tags da especificação do CPL, nas
próximas versões, pretendemos incluir estas, principalmente a de roteamento por
horário.
Com relação ao ambiente heterogêneo, na adoção deste framework de
programação de chamada CPL, cada ambiente (SIP ou H.323) terá a capacidade de
executar alguma programação de serviço definida pelo usuário. No caso do SIP, isso
pode ser feito pelo servidor SIP Proxy com extensão CPL, no caso H.323, pelo servidor
93
H.323 GK com extensão CPL. Para migrar uma programação de serviço de um
ambiente para o outro, basta compartilhar os scripts, que semânticamente tem o mesmo
significado para ambas as arquiteturas.
Entretanto as abordagem de programação de serviços por serviços suplementares
são também muito importantes, e que, para implementá- los na nossa arquitetura
heterogênea de telefonia IP, precisamos estender o paradigma da programação CPL,
usando o que chamamos de CPL Interativo.
O CPL Interativo seria a execução de um script CPL durante uma chamada
telefônica IP. Este script, contendo uma lógica de serviço suplementar, deve ter o
mesmo significado tanto nos ambiente H.323 quanto SIP, ou outros. Para realizar estes
objetivos, é preciso fazer um estudo mais aprofundado do mapeamento entre as
mensagens complexas de SIP e H.323. A linguagem formal que define os padrões de
serviços suplementares no H.323, chamada SDL (Specification and Description
Language Diagrams) é uma boa candidata a ser a base para este mapeamento e posterior
criação da extensão de CPL interativo. Pois ela descreve formalmente no protocolo
H.323 qual é o grafo de execução de cada serviço suplementar.
Outros pontos fundamentais para a base do CPL Interativo é que ele deve ser
implementado dentro dos servidores GK (usando o modo GK Routed), não provocando
qualquer ônus ou reimplementação por parte dos terminais H.323. E sua ativação dos
serviços deverá ser feita através de uma interface Web, durante a comunicação de
telefonia IP, pois não é possível usar mime-types no H.323 para fazer este serviço via
mensagens Facility.
Um objetivo futuro é a implementação de um protótipo deste CPL Interativo.
94
REFERÊNCIAS
[1] NICHOLS, K.; BLAKE, S.; BAKER, F.; BLACK, D. Definition of the
Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers . IETF
RFC 2474. dez. 1998.
[2] SCHULZRINNE, H.; CASNER, S.; FREDERICK, R.; JACOBSON, V. RTP: A
Transport Protocol for Real-Time Applications. IETF RFC 1889, jan. 1996.
[3] SCHULZRINNE, H.; ROSENBERG, J., et al. SIP: Session Initiation Protocol.
IETF RFC 2543. outubro 2001.
[4] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.323: Packet-Based Multimedia Communications
Systems . Setor de Telecomunicações da ITU. Genova, Suiça. setembro, 1999.
[5] ROSENBERG, J. Parched For Services? Here, Try A SIP. Communications
Solutions. Disponível em http://www.tmcnet.com/articles/comsol/0500/
0500ays_rosenberg.htm. Acessado em maio de 2000.
[6] ARANGO, M.; DUGAN, A.; ELLIOT, I.; HUITEMA, C. e PICKETT S.
MGCP: Media Gateway Control Protocol. IETF RFC 2705. outubro 1999.
[7] FREED, N.; BORENSTEIN, N. Multipurpose internet mail extensions
(MIME) part two: Media types. IETF RFC 2046, nov. 1996.
[8] RIBEIRO, B., RODRIGUES, P., MARCONDES, C. Implementação de
Gateway de Sinalização entre Protocolos de Telefonia IP SIP/H.323. SBRC
2001, Florianópolis, maio 2001.
[9] POZO, I. E. DEL. An Implementation of the Call Waiting Service using SIP.
Tese de Mestrado da Universidade Tecnológica de Helsinki e Universidade
Politécnica de Valência. dezembro 1999.
95
[10] EGOBOO INC. Código Fonte do Opengatekeeper. Disponível em
http://opengatekeeper.sourceforge.net. Acesso em: 30 ago. 2001.
[11] SINGH, K.; SCHULZRINNE, H. Interworking Between SIP/SDP and H.323.
Anais do 1o Workshop de Telefonia IP (IPTel’2000), Berlim, Alemanha, abril,
2000.
[12] DOUSKALIS, B. IP Telephony The Integration of Robust VOIP Services.
Hewlett-Packard Professional Books, Prentice Hall, Inc., 2000.
[13] POZO, E. I.; COSTA, M. J.; KANTOLA, R. New Tools for Programming IP
Telephony Service. Anais do 1o Workshop de Telefonia IP (IPTel’2000),
Berlim, Alemanha, abril, 2000.
[14] ECKEL, B. Thinking in Java, 2nd Edition, MindView Inc, junho 2000.
[15] CISCO SYSTEMS. Voice Over IP for the Cisco 2600 Series. Disponível em
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/
113t_3/ voip2600.htm. Acesso em: 30 ago. 2001.
[16] SOURCEFORGE GROUP. Código Fonte do Projeto OpenH323Proxy.
Disponível em http://openh323proxy.sourceforge.net. Acesso em ago. 2001.
[17] EQUIVALENCE INC. Código Fonte do Projeto OpenH323 e OpenGk,
Disponível em http://www.openh323.org . Acesso em: 20 dez. 2000.
[18] CISCO SYSTEMS. Understanding H.323 Gatekeepers . Disponível em
http://www.cisco.com/warp/public/788/voip/understand-gatekeepers.html.
Acesso em jan. 2002.
[19] ROSENBERG, J.; LENNOX, J.; SCHULZRINNE, H. Programming Internet
Telephony Services. Revista IEEE Network, vol. 13, pp. 42–49, maio/junho
1999.
[20] LENNOX, J.; SCHULZRINNE, H. CPL: A language for user control of
internet telephony services. IETF Internet Draft, março 2001. Em andamento.
[21] MARTIN, D. e ANDERSON, R. Professional XML. Editora Ciência Moderna.
2001
96
[22] ROSENBERG, J. Distributed Algorithms and Protocols for Scalable Internet
Telephony. Tese de Doutorado, Universidade de Columbia, New York, maio de
2001.
[23] UNIVERSIDADE DE COLUMBIA, NY. SIPD – Servidor Proxy e Redirect
SIP com Extensões CPL. Disponível em
http://www.cs.columbia.edu/~lennox/sipd. Acesso em 20 dez 1999.
[24] LENNOX, J.; SCHULZRINNE, H. Call Processing Language Framework
and Requirements. IETF RFC 2824. maio 2000.
[25] LENNOX, J.; SCHULZRINNE, H. Transporting User Control Information
in SIP REGISTER Payloads . IETF Internet Draft, março 2001. Em andamento.
[26] APACHE GROUP. Código Fonte da Biblioteca de Manipulação XML:
Xerces para Java e C++. Disponível em http://xml.apache.org. Acesso em 30
set. 2001.
[27] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.323 Annex O. Use of Complementary Internet
Protocols with H.323 Systems . Setor de Telecomunicações, Genova, Suiça.
março 2001.
[28] JACKSON, M.; ZAVE, P. Distributed Feature Composition: A Virtual
Architecture for Telecommunications Services. IEEE Transaction on
Software Engineering, vol. 24, n. 10, pp. 831-847, outubro 1998.
[29] BEDDUS, S.; BRUCE; G.; DAVIS, S. Opening Up Networks with JAIN
Parlay. Revista IEEE Communications, abril 2000.
[30] JACKSON, M.; ZAVE, P. DFC as the basis for ECLIPSE, an IP
communications software platform. Anais do IP Telecom Services Workshop,
Atlanta, EUA, set. 2000.
[31] SUN MICROSYSTEMS. Projeto da Arquitetura JAIN (PARLAY em Java).
Disponível em http://java.sun.com/jain. Acessado em set. 2001.
[32] WU, X.; SCHULZRINNE, H. Where Should Services Reside in Internet
Telephony Systems? Anais do IP Telecom Services, Atlanta, EUA. pgs. 35-40.
set. 2000.
97
[33] LENNOX, J. E SCHULZRINNE, H. Feature Interaction in Internet
Telephony. Anais do Feature Interaction in Telecommunications and Software
Systems VI. Glasgow, Reino Unido. maio 2000
[34] SUN MICROSYSTEMS. Página Web de Instalação do Java Plugin.
Disponível em http://java.sun.com/products/plugin/. Acesso em 30 dez. 2001.
[35] GALLANT, M. Working Example Signed with Self-signed Certificate.
Disponível em http://204.191.136.6/~neutron/testsscert/index.html. Acessado
em: 3 de jan. 2002.
[36] SCHULZRINNE, H. Classification for SIP Interoperability Test Event.
Disponível em http://www.cs.columbia.edu/~hgs/sip/sipit/classification.html.
Acessado em 10 de julho de 2001.
[37] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST).
Projeto de Stack e Parser SIP. Disponível em
http://snad.ncsl.nist.gov/proj/iptel/. Acessado em jan. 2001.
[38] AFONSO, F. C. Virtual Reality Transfer Protocol (VRTP). Implementing a
Monitor Application for the Real-Time Transport Protocol (RTP) using the
Java Media Framework (JMF). Escola Naval de Pós-Graduação, Tese de
Mestrado em Ciência da Computação, Monterey, California, EUA, setembro
1999.
[39] GAMMA, E., et al. Design Patterns – Elements of Reusable Object-Oriented
Software . Addison Wesley Longman, 1995.
[40] CROCKER, D.; OVERELL, P. IETF RFC 2234 – ABNF: Augmented BNF
for Syntax Specifications . novembro de 1997.
[41] ANTLR GROUP. Webiste do Projeto ANTLR. Disponível em
http://www.antlr.org/. Acesso em 10 jul, 2001.
[42] AHO, A. V.; SETHI, R.; ULLMAN, J. D. Compilers: Principles, Techniques
and Tools. Addison-Wesley, 1986.
[43] SUN MICROSYSTEMS. Java Media Framework API Guide . Disponível em
http://java.sun.com/products/java-media/jmf/. Acessado em nov. 1999.
98
[44] SCHULZRINNE, H. Website Oficial do SIP – SIPIT: SIP Interoperability
Test. Disponível em http://www.cs.columbia.edu/~hgs/sip/sipit/. Acessado em
fev. 2001.
[45] INTERNATIONAL MULTIMEDIA TELECONFERENCING CONSORTIUM.
SIP Interoperability Scenarios Test Plan. jun. 2000
[46] INTERNATIONAL TELECOMMUNICATION UNION (ITU). Appendix II to
Recommendation G.711: A Comfort Noise Payload Definiton for ITU-T
G.711 Use in Packet-Based Multimedia Communication Ststems . Setor de
Telecomunicações, Genova, Suiça. (a ser publicado)
[47] ZOPF, R. RTP Payload for Comfort Noise. IETF Draft. jan. 2002. Trabalho
em andamento.
[48] GULBRANDSEN, A.; VIXIE, P.; e ESIBOV, L. A DNS RR for specifying the
location of services (DNS SRV). IETF RFC 2782, fev. 2000.
[49] LINUX MAGAZINE. Using BIND Name Servers with Windows 2000.
Disponível em : http://www.linux-mag.com/2001-03/bind_03.html. Acesso em:
jan. 2002.
[50] CISCO SYSTEMS. Digital T1/E1 Packet Voice
Trunk Network Module. Disponível em: http://www.cisco.com
/warp/public/cc/ pd /rt/2600 /prodlit/st1e1_ds.htm. Acesso em jan. 2002.
[51] JIANG, W.; LENNOX, J.; SCHULZRINNE, H. e SINGH, K. Towards
Junking the PBX: Deploying IP Telephony. Network and Operating System
Support for Digital Audio and Video (NOSSDAV), New York, jun. 2001.
[52] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.225.0: Media Stream Packetization And
Synchronization On Non-Guaranteed Quality Of Service LANs. Setor de
Telecomunicações, Genova, Suiça. nov. 1996.
[53] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.245: Security and Encryption for H Series (H.323 and
other H.245 based) multimedia terminals. Setor de Telecomunicações,
Genova, Suiça. jan. 1998.
99
[54] INTERNATIONAL TELECOMMUNICATION UNION (ITU). Annex G of
the H.225.0 recommendation: Communication Between Administrative
Domains. Setor de Telecomunicações, Genova, Suiça. jan. 1998.
[55] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.235: Security and Encryption for H Series (H.323 and
other H.245 based) multimedia terminals. Setor de Telecomunicações,
Genova, Suiça. jan. 1998.
[56] QUICKNET INC. Placa Linejack. Disponível em: http://www.quicknet.com/
products/ilj.htm. Acesso em: jan. 2000.
[57] CISCO SYSTEMS. Cisco IOS Release 12.2. Disponível em:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/. Acesso em
ago. 2001.
[58] CISCO SYSTEMS. Configuring Access Control Lists. Disponível em:
http://www.cisco.com/univercd/cc/ td /doc /product/lan /cat6000/sw_5_4/ msfc/
acc_list.htm. Acesso em: fev. 2002.
[59] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.450.1: Generic functional protocol for the support of
supplementary services in H.323. Setor de Telecomunicações, Genova, Suiça.
setembro 1997.
[60] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation H.450.2: Call Transfer Supplementary Service For H.323.
Setor de Telecomunicações, Genova, Suiça. set. 1997.
[61] SPARKS, R. IETF Draft: SIP Call Control. Disponível em
http://www.cs.columbia.edu/~hgs/sip/drafts/draft- ietf-sip-cc-transfer-04.txt.
Acesso em ago. 2001. Em andamento.
[62] MUQUIT, M. Código Fonte do Programa em Perl para Upload de Arquivos.
Disponível em http://www.muquit.com/muquit/software/
upload_pl/upload_pl.html. Acesso em set. 2000.
100
[63] INTERNATIONAL TELECOMMUNICATION UNION (ITU).
Recommendation X.680: Abstract Syntax Notation One (ASN.1)
Specification of Basic Notation. Setor de Telecomunicações, Genova, Suiça,
1996.
[64] UNIVERSIDADE TECNOLÓGICA DE VIENA e UNIVERSIDADE
TÉCNICA WIEN. Interpretador CPL em Java: cplParser. Disponível em
http://www.ikn.tuwien.ac.at/ftw-a1/. Acesso dez. 2001.
[65] LENNOX, J. Cal-Code: Java code for CPL time-switches. Disponível em:
http://www.cs.columbia.edu/~lennox/Cal-Code/. Acesso: Dez. 2001.
101
ANEXO 1
AMBIENTE SIP
O SIP (Session Initiation Protocol) é um protocolo no nível de aplicação da
IETF, que estabelece, modifica e termina sessões multimídia e/ou ligações. Estas
sessões podem ser conferências multimídia, aulas pela Internet, telefonia sobre Internet,
entre outras. Na Figura A.1 apresentamos um ambiente SIP genérico.
Os três componentes principais do SIP são: o SIP User Agent, o SIP Proxy
Server e o SIP Redirect Server. O conjunto destes componentes atuando em uma rede IP
é definido como ambiente de “rede” SIP. Estes componentes SIP são descritos na tabela
abaixo.
Componente SIP Função SIP User Agent Cliente da arquitetura, ou o ponto final da comunicação multimídia. SIP Proxy Server Servidor de redirecionamento de requisições e respostas SIP. Passa a realizar a
sinalização como se fosse o originador da chamada, e quando a resposta lhes é enviada, ela é redirecionada para o originador real.
SIP Redirect Server Redireciona requisições e respostas, enviando uma mensagem para os clientes com o novo endereço SIP procurado, e não fazendo o papel de continuar a chamada.
SIP Registrar Server Servidor SIP que suporta requisições REGISTER, usadas para registrar as informações dos usuários em algum Servidor de Localização.
Servidor de Localização Na RFC do SIP, apenas as funcionalidades de armazenamento e consulta de registros de usuários SIP neste servidor são descritas, ficando a critério do implementador da solução SIP a escolha da melhor tecnologia para esta finalidade.
A “rede” SIP (fig. A.1) pode ser acessada via Internet usando uma URI
(Uniform Resource Identifier). A URI é uma string compacta para endereçar os recursos
físicos ou abstratos dentro da rede. Exemplos de endereçamentos SIP são "alias" (ou
apelido) como esta URI <sip://usuário@servidor> ou pode ser um # de telefone, como
<tel://[email protected]>. A parte do host na identificação URI pode ser um domínio
internet alfanumérico válido ou um endereço IP numérico.
102
Fig. A.1 – Ambiente de Telefonia IP SIP
O protocolo SIP é baseado no HTTP e, assim como este, suporta o transporte de
qualquer tipo de carga em seus pacotes, pelo uso de Mime-Types (Multipurpose Internet
Mail Extensions). O SIP funciona numa arquitetura cliente/servidor, e suas operações
envolvem apenas métodos de requisição e respostas, como observado também no HTTP
e no RTSP. Os métodos de requisição do SIP são os seguintes: INVITE, ACK,
OPTIONS, BYE, CANCEL, e REGISTER. O comportamento destes métodos é descrito
na tabela abaixo.
Nome do Método
Comportamento
INVITE Indica que o usuário está sendo convidado a participar de uma sessão multimídia. O corpo da mensagem pode conter uma descrição da sessão, utilizando-se o protocolo de descrição de sessão SDP (Session Description Protocol)[4].
ACK Mensagem recebida como resposta final a um INVITE. A requisição ACK pode conter o SDP de descrição da sessão negociada entre ambos os clientes. Se não contiver o SDP, o usuário chamado pode assumir a descrição dada pelo primeiro INVITE, se houver.
OPTIONS Faz uma pergunta sobre quais métodos e extensões são suportados pelo servidor e pelo usuário descrito no campo de cabeçalho <To:> . O servidor pode responder a esta pergunta com o conjunto de métodos e extensões suportado pelo usuário e por ele mesmo.
BYE Usado para liberar os recursos associados a uma ligação e forçar a desconexão da mesma.
CANCEL Cancela uma requisição que ainda esteja pendente, ou seja, em andamento. Uma requisição é considerada pendente, se e somente se, ela não foi atendida com uma resposta final.
REGISTER Um cliente usa este método para registrar o "alias" (apelido) do seu endereço em algum servidor SIP, que, por aceitar registro de usuários, chamamos de serviço REGISTRAR.
103
Dentro da arquitetura SIP, muitas vezes temos a figura de um servidor de
localização, onde ficam os registros de usuários. Normalmente, para a localização destes
nomes, são usadas bases de dados locais ou servidores LDAP (Lightweigth Directory
Access Protocol), onde é possivel montar diretórios de usuários e seus perfis.
Para cada requisição ou resposta, temos um grupo de cabeçalhos, dividos em:
cabeçalhos gerais, com informações importantes sobre a chamada; cabeçalhos de
entidade, com meta-informação sobre o corpo da mensagem; e os cabeçalhos
específicos, que permitem passar informações adicionais, que não couberam na linha de
status da requisição ou da resposta.
Quando requisições são atendidas, as respostas enviadas são identificadas por
números, que significam a classe da resposta. Pode-se enviar diversas mensagens
provisórias antes de se enviar uma resposta definitiva. Existem seis classes possíveis de
resposta: Classe 1XX, respostas temporárias ou informativas (180 Ringing); Classe
2XX, resposta final de sucesso (200 OK); Classe 3XX, redirecionamento da requisição
(301 Moved Permanently); Classe 4XX, erros no cliente (407 Proxy Authentication
Required); Classe 5XX, erros do servidor (501 Not Implemented); e Classe 6XX, erros
globais na rede (600 Busy Everywhere).
Na Figura A.2, temos o exemplo de um fluxo de convite para um usuário na
“rede” SIP, mostrando características de mobilidade do usuário, mensagens de
requisição, e mensagens de resposta finais. Acompanhe na Figura 2 as descrições
numeradas a seguir:
Fig A. 2 – Estabelecimento de Chamada em SIP
104
(1) Usuário bruno pede para ser criada uma sessão entre ele e o usuário de "alias" [email protected]. [Requisição SIP INVITE]
(2) O servidor proxy então pergunta ao servidor de localização de usuários (Location Server Database) onde está o usuário com esse "alias" [usando o Protocolo LDAP].
(3) A resposta deste servidor é a atual localização do usuário (esta é a caracteristica de mobilidade na rede SIP. Seu último REGISTER partiu de ipanema.land.ufrj.br).
(4) A requisição de abertura de sessão é então redirecionada pelo proxy para o endereço correto [Requisicao SIP INVITE]. Então, o usuário cesar na máquina ipanema.land.ufrj.br será alertado, recebendo o toque de chamada [RING-RING].
(5) Cesar decide se juntar à sessão e o seu cliente SIP responde para o servidor proxy que a sessão pode ser aberta [Resposta de Sucesso 200 OK para o Servidor Proxy].
(6) O servidor proxy redireciona essa resposta ao cliente chamador [Resposta de Sucesso 200 OK redirecionada para bruno].
(7) O cliente chamador bruno indica para o servidor que a negociação da sessão acabou e a sessão está aberta [Requisição ACK contendo a negociação final de mídia].
(8) Enfim, o servidor proxy indica para o cliente chamado que a negociação da sessão acabou e a sessão está aberta [Requisição ACK contendo a negociação final de mídia].
105
ANEXO 2
AMBIENTE H.323
A recomendação H.323 conceitualmente descreve terminais, equipamentos e
serviços para comunicação multimídia sobre redes locais sem garantia de qualidade de
serviço (QoS). Terminais e equipamentos H.323 podem transportar voz em tempo real,
dados e vídeo ou qualquer combinação destes, como a videotelefonia.
A LAN sobre a qual os terminais H.323 se comunicam pode ser um só segmento
de rede, ou podem ser múltiplos segmentos, com topologias mais complexas.
Entretanto, deve-se lembrar que a operação do H.323 sobre múltiplos segmentos de rede
local, incluindo-se seu uso com a Internet, pode resultar em perda de escalabilidade.
No H.323, o usuário se registra em um elemento de rede chamado Gatekeeper
(GK). O GK é um servidor cujas principais funções são o controle de admissão de
ligações, decrementando de um valor presumido de banda disponível a cada admissão, e
a procura por usuários H.323 registrados. O H.323 é baseado na noção de domínios
administrativos. Domínio administrativo é o conjunto de GKs que são considerados
vizinhos, ou seja, aqueles servidores que estão dentro da mesma região administrativa,
mas têm registros de clientes diferentes.
Terminais H.323 podem ser implementados em software em PCs ou integrados
em dispositivos independentes como videofones, ou IPfones. Na recomendação, o
suporte a voz é obrigatório, enquanto suporte a transporte de dados e vídeo são aspectos
opcionais. O H.323 abstrai o transporte das mídias, tratando-o como um canal. Ele
permite que mais de um canal seja usado para cada tipo de mídia. Existem outras
recomendações que fazem parte da pilha de protocolos do padrão H.323. São elas:
H.225.0, para mensagens RAS (Requisição, Admissão e Status) e sincronização; H.245,
para controle de mídia; H.261 e H.263, para codificação e decodificação de vídeo;
G.711, G.722, G.728, G.729, e G.723, para codificação e decodificação de áudio; e
T.120, para protocolos de comunicação de dados.
106
O H.323 usa os procedimentos de abertura de canais lógicos descritos na
recomendação H.245, onde cada sessão de mídia corresponderá a um canal. Antes de
abrir o canal, os terminais já trocaram mensagens sobre o conjunto de capacidades,
orientados pelo H.245, e sabem quais as mídias que podem receber/enviar e quais os
transportes suportados pelo outro terminal.
Fig. B.1 – Zona Administrativa H.323 e Diversos Componentes
A parte de sinalização e estabelecimento de chamada do H.323 é baseada na
norma de telefonia ISDN Q.931, usando as extensões definidas pela norma H.225 para o
campo opcional User-to-User (SETUP UUIE). Assim, toda a negociação de controle de
chamada básica é feita pela Q.931/H.225, ficando apenas a negociação de mídia para o
H.245. Na arquitetura descrita pela recomendação H.323 para a Telefonia IP, existem
vários elementos fundamentais (Figura B.1).
Na tabela a seguir, temos a descrição dos componentes da Figura B.1.
Componente H.323 Função Terminais H.323 São os clientes da arquitetura, ou ponto finais da comunicação. Gatekeeper São responsáveis por manter o registro dos clientes, capazes de achar um cliente
registrado em outro GK, e podendo fazer uso de serviços de diretórios (LDAP). MCU Possui funções de controle para suporte a conferências entre três ou mais pontos
terminais em uma conferência multiponto. Gateway PSTN Provê a tradução apropriada entre formatos de transmissão e procedimentos de
comunicação, além de gerar e detectar sinais DTMF (Dual-Tone MultiFrequency), correspondendo à sinalização do H.245 (necessário para interação com a PSTN).
Border Element Responsável pela interface entre duas regiões administrativas H.323.
A sinalizacao H.323 é extremamente complexa, devido principalmente a sua
extensa pilha de protocolos, e a conformidade com padrões antigos da ITU-T. Na figura
B.2, temos uma idéia dessa complexidade. As mensagens ARQ (Admission Request, ou
pedido de abertura de sessão), ARJ (Admission Reject, ou a rejeição do pedido) e ACF
107
(Admission Confirm, ou a confirmação do pedido), são exclusivas dos terminais H.323.
Estas mensagens, em conjunto com LRQ (Location Request), LCF (Location Confirm),
LRJ (Location Reject), usadas pelos gatekeepers, formam o que denomina-se conjunto
de mensagens RAS (Requisição, Admissão e Status). Um terminal registrado em um
GK sempre pedirá autorização ao GK para iniciar e/ou aceitar chamadas de telefonia IP.
As mensagens Q.931 são SETUP (estabelecimento de chamada ISDN), Call Proceeding
(equivalente ao Ringing do SIP) e CONNECT (confirmação do estabelecimento de
chamada).
Fig. B.2 – Fluxo da Sinalização segundo o H.323 v1
Na fase de inicialização de mídia pelo H.245, uma porta TCP é aberta para
negociação dos subconjuntos de mídias suportados e a ordem de preferência das mídias.
O canal H.245 é mantido aberto caso alguém abra uma nova sessão de mídia, ou
modifique uma existente. As mensagens mais básicas do H.245 são: Capability
Exchange (troca de conjuntos de capacidades de mídia entre os terminais), Open
Logical Channel (abertura de canal de controle do fluxo de mídia) e Open Logical
Channel Acknowledge (confirmação do mesmo). O transporte do fluxo de mídia, após a
fase de negociação, acontece no nível de rede pelo uso do protocolo de transporte RTP
(Real time Transport Protocol), sendo este também usado pelo SIP, para transporte de
mídia.