implantação e desenvolvimento de serviços para
Transcrição
implantação e desenvolvimento de serviços para
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ósGraduaçã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 Webto-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 ABNF ACF ACL APDU API ASN.1 BSM CESNET CGI CNAME CPL DFC DGK DHCP DNS DSCP DTD EBNF FDM FSMUA FXO FXS GK GNU GRQ GW HTML HTTP HUT IETF IMTC IOS IP ISDN ISUP ITSP ITU-T JAIN JAR JMF JNI Australian Research Network Augmented Backup-Naur Form Admission Confirm Access Control List Application PDU Application Programming Interface Abstract Syntax Notation One Basic Signaling Messages Czech Research Network Common Gateway Interface Canonical Name Call Processing Language Distributed Feature Connection Directory Gatekeeper (H.323) Dynamic Host Configuration Protocol Domain Name System Differentiated Services Code Point Document Type Definition Extended Backus-Naur Form Frequency Division Multiplex Finite State Machine User Agent Foreign Exchange Office Foreign Exchange Station Gatekeeper (H.323) GNU’s Not Unix Gatekeeper Request Gateway Hypertext Markup Language Hypertext Transfer Protocol Helsinki University of Technology Internet Engineering Task Force International Multimedia Teleconferencing Consortium Internetworking Operating System Internet Protocol Integrated Services Digital Network ISDN User Part Internet Telephony Service Provider International Telecommunication Union Java API Integrated Networks Java Archive Java Media Framework Java Native Interface JRE JVM LAN LRQ MG MGC MGCP MIB MIME NAT PBX PCM PDU PSTN QoS RAS RFC ROS RRQ RTCP RTP RTT SDL SDP SET SIP SMTP SS7 TCP TOS UDP URL VOIP XML YACC Java Runtime Environment Java Virtual Machine Local Area Network Location Reject Media Gateway Media Gateway Control Media Gateway Control Protocol Management Information Base Multipurpose Internet Mail Extensions Network Address Translation Private Branch Exchange Pulse Code Modulation Protocol Data Unit Public Switched Telephone Network Quality of Service Registration/Admission/Status Request for Comments Remote Operations Service Registration Request Real Time Control Protocol Real Time Transport Protocol Round-Trip Time Specification and Description Language Session Description Protocol Simple Endpoint Type Session Initiation Protocol Simple Mail Transfer Protocol Signaling System 7 Transmission Control Protocol Type of Service User Datagram Protocol Uniform Resource Locator Voice over IP Extensible Markup Language Yet Another Compiler Compiler vi LISTA DE FIGURAS Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8 Figura 9 Figura 10 Figura 11 Figura 12 Figura 13 Figura 14 Figura 15 Figura 16 Figura 17 Figura 18 Figura 19 Figura 20 Figura 21 Figura 22 Figura 23 Figura 24 Figura 25 Figura 26 – Um exemplo do funcionamento da rede virtual Eclipse – Interação de Serviços sob o Ponto de vista do Ambiente Heterogêneo – Decisão sobre liberar os recursos usando Certificado Auto-Gerado – Implementação UFRJ SIP Client – Diagrama de Classes do Módulo de Transporte da Sinalização SIP – Diagrama de Classes do Módulo de Geração de Mensagens SIP – Gerenciamento da Máquina de Estados SIP – Classes de Transmissão e Recepção de Áudio – Utilização do JMF Registry para habilitar captura de áudio pela Applet – Arquitetura do Laboratório VOIP/UFRJ – Interfaces FXS e FXO – 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. – Programa openphone em execução – Diagrama de Classes do Opengatekeeper – Diagrama de Classes do OpenGK – Arquitetura de Telefonia IP do Laboratório VOIP – Problema de Location Request entre Sites VOIP da Internet2 – Configuração do Grupo VOIP Internet2 – Serviço Suplementar Call Transfer H.323 (A) Serviço Suplementar Call Transfer e (B) Implementação de Call Transfer no OpenPhone – Editor Gráfico de CPL e Gerador do XML correspondente ao grafo CPL – Diagrama de Classes da Parte Gráfica do Editor CPL – Diagrama de Classes da Parte XML do Editor CPL – Instalador CPL para Ambiente H.323 – Diagrama de Classes das Mensagens RAS/H.225 – Diagrama de Classes do GK com Extensão CPL – Fluxo Básico do Redirecionamento por Endereço (h323- id) vii LISTA DE QUADROS Quadro 1 Quadro 2 Quadro 3 Quadro 4 Quadro 5 Quadro 6 Quadro 7 Quadro 8 Quadro 9 Quadro 10 Quadro 11 Quadro 12 Quadro 13 Quadro 14 Quadro 15 Quadro 16 Quadro 17 Quadro 18 Quadro 19 Quadro 20 Quadro 21 Quadro 22 – Diferenciação da mensagem SIP através do Parsing da primeira linha – Trecho do Código da Montagem da mensagem ACK com NIST-SIP – Trecho do Código em Java da Sequencia de Captura de Áudio e Transmissão via RTP – Callback da Classe AudioReceive do SIPApplet para capturar mudança de payload – Entrada DNS SRV para SIP do laboratório VOIP com distribuição de carga – Configuração Básica do Roteador Cisco 2600 para Suporte SIP – Mensagem de Status SIP do Cisco 2600 obtida com o comando: debug ccsip all – Configuração do Opengatekeeper Local – Trecho do Log do Opengatekeeper usado para calcular o tempo da ligação – Configuração das Interfaces e Planos de Discagem do Gateway Cisco 2600 – Configuração da Interface Gateway para Registro no GK – Configuração dos Dial-peers da Internet2 – Tabela de Serviços Suplementares H.323 – Exemplo de Script CPL de Roteamento pela Hora do Dia – Diferenças para os nós Incoming e Outgoing – Diferenças para os nós Address-Switch contendo parâmetro field – Diferenças pra os nós Address-Switch contendo parâmetro sub-field – Diferenças para os nós String-Switch contendo parâmetro field – Diferenças para os nós Location contendo parâmetro url – Diferenças para os nós Lookup – Trecho do Código de verificação se o campo GatekeeperIdentifier tem o mesmo ID do GK – CPL/XML de Serviço de Redirecionamento por Endereço viii LISTA DE TABELAS Tabela 1 Tabela 2 Tabela 3 – 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) – Resultados de cinco observações dos testes no Cenário 1 de Interoperabilidade entre Clientes SIP (Ponto-a-Ponto) (segundo IMTC) – 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 – P ROTOCOLOS SIP, H.323 E MGCP..............................................................................................................5 1.4 – A MBIENTE HETEROGÊNEO DE TELEFONIA IP.............................................................................................7 1.5 –SERVIÇO W EB-TO-DIAL..................................................................................................................................8 1.6 –IMPLANTAÇÃO DE A MBIENTE H.323..........................................................................................................10 1.7 – INTRODUÇÃO À PROGRAMAÇÃO DE SERVIÇOS NO A MBIENTE HETEROGÊNEO...................................11 1.8 – F RAMEWORK DE PROGRAMAÇÃO DE SERVIÇOS PARA AMBIENTE HETEROGÊNEO ............................13 1.9 – P ROGRAMAÇÃO DE SERVIÇOS USANDO PARLAY/DFC ...........................................................................14 1.10 – COMPARAÇÃO ENTRE PROGRAMAÇÃO DE SERVIÇO USANDO PARLAY/DFC E A MBIENTE 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 A VANÇ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, usase 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 principalment e 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 reroteamento 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 impleme ntaçã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. Agente de Vendas Telefone Outro Usuário Line Interf. Call Wait. Instant Mess. Agent Line Interf. Telefone Vendedor AOL Instant Mess. Line Interf. 0800 Call Transfer Telefone Novo Cliente Computador com AOL IM 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). Agente de Vendas Fluxo RTP Fluxo RTP Telefone Outro Usuário Gateway PSTN/SIP SIP MESG Servidor SIP Proxy + CPL INVITE Telefne Novo Cliente Gateway PSTN/H.323 H.22 5R SETU AS P Gateway SIP/Instant Message Telefone Vendedor MESG LRQ SETUP Gatekeeper + CPL Computador com ICQ IM Gateway SIP/H.323 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. 2.1.1 – Trabalhando com Applets Assinadas para acessar Serviços Remotos de Rede 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. 21 Fig. 3 – Decisão sobre liberar os recursos usando Certificado AutoGerado 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 Fig. 4 – Implementação UFRJ SIP Client 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/ ContentLength/ 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 impleme ntaçã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. 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 SIPJAIN. 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 topdown 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) 300 iterações : tempo de 548,04 ms 300 iterações : tempo de 670,03 ms 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) 300 iterações : tempo de 1443,29 ms 300 iterações : tempo de 661 ms INVITE inicial ACK após o recebimento de 200 OK 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 NISTSIP 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. 2.4.1 – Detalhamento do Módulo de Transmissão e Recepção de Áudio RTP 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 trans mitida 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 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 2 3 4 5 6 7 8 9 10 11 dataOutput = Manager.createDataSource(new MediaLocator("dsound://44100")); processor = Manager.createProcessor(dataOutput); boolean result = waitForState(processor, Processor.Configured); TrackControl [] tracks = processor.getTrackControls(); ContentDescriptor cd = new ContentDescriptor(ContentDescriptor.RAW_RTP); tracks[5].setFormat(AudioFormat("ULAW/rtp", 8000, 8, 0); result = waitForState(processor, Controller.Realized); dataOutput = processor.getDataOutput(); sendStream = rtpManager.createSendStream( dataOutput, 0); sendStream.start(); 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 2.4.2 – Questões de Desempenho do Pacote JMF Performance Pack 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. 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 Cliente SIP Ubiquity Cliente SIP Versão 1.6 Versão 2.0 Hughes 1.0 Cliente SIP Funcionou bem nas várias Funcionou bem nas várias Funcionou Applet (Web tentativas diferentes. Entretanto tentativas. Tivemos entretanto que perfeitamente to Dial) apresentou instabilidade resolver um problema, que não frente a principalmente com a transmissão deveria acontecer neste cliente, ao vários testes de mídia via RAT e recepção de ser usado um caracter espaço a diferentes. BYE. mais no cabeçalho origin do SDP. 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. Cliente SIP Applet (Web to Dial) Servidor SIP Columbia Versão 1.17 Funcionou bem para o cenário local. Servidor SIP NIST 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. 2.5.1 – Problema da Interoperabilidade dos Fluxos de Mídia entre Gateway SIP/PSTN (Cisco 2600) e Java Media Framework (JMF) 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 implement amos (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) 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. Interface VIC FXO Gateway de Sinalização SIP/H.323 Microsoft Netmeeting Roteador Cisco 2600 Central Telefonica NCE/UFRJ Gateway da Rede VOIP Servidor Proxy SIP Servidor Web da SIP Client Applet Firewall Ramal 3354 Internet Internauta 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. 2.6.1 – Configurações do Gateway SIP/PSTN Cisco 2600 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. 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 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 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. 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. Endpoint (Netmeeting) Gatekeeper Gatekeeper Gatekeeper (A) Alternate Gatekeepers Gatekeeper Gatekeeper Gatekeeper Gateway 23% Gateway 64% Gateway 77% Gateway 36% (B) Endpoint Capacity Reporting Gateway Composto MGC MGC MG MG MG MG Gateway Decomposto MG MG MG MG MG MG (C) Decomposição do Gateway 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 Fig. 13 –Programa openphone em execução 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 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 3.2.1 – Implantação e Testes das Ferramentas H.323 no Laboratório VOIP 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. 3.2.2 – Estudo sobre Gatekeepers H.323 baseado no OpenH323 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. 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 emailid, 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. 3.2.3 – Implantação de Ambiente H.323 no Laboratório VOIP 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. 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 [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 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 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. 3.2.4 – Logando Ligações no Ambiente UFRJ 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 { callReference = 25930 messageType = Setup IE: Display = { 4d 61 6e 75 65 6c 20 41 6e 69 64 6f 00 } IE: Called-Party-Number = { 81 35 35 32 31 32 32 34 32 38 30 30 34 } Q.931 01:15:27 16/01/2002 Recv 128.200.9.21:3174 { callReference = 25930 from = originator messageType = ReleaseComplete } Q.931 Manuel Anido. .55212598XXXX Quadro 9 – Trecho do Log do Opengatekeeper usado para calcular o tempo da ligação 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). Central Telefônica CCMN/NCE Internet Hub 10/100 Tronco Telefonico UFRJ FXO int 3186 eth0/0 Gateway da Rede (máquina RIO) OpenGatekeeper (máquina vitória) FXS 3190 FXO 3191 Roteador Cisco 2600 Telefone Virtual 3190 Fig. 16 – Arquitetura de Telefonia IP do Laboratório VOIP 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 convencio nal. 57 3.3.1 – Configurações Iniciais do Roteador Cisco 2600 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á 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 configurada para gerar tom de discagem padrão brasileiro (cptone BR). Os outros voiceport (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 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 mensage ns 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. 3.4.1 – Configuração de Dial -Peer para os Sites de VOIP da Internet2 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. 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 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 Dialpeers da Internet2 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. 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. GK Diretório Univ. Indiana PBX Situação 1 Discando para Austrália GK Diretório AARNET PBX LRQ Telefone LRQ Situação 2 Discando para EUA Telefone Internet2 LCF LCF GW Cisco 2600 GK UFRJ I2GK=134.68.106.10 AARNET=203.22.212.245 Fig. 17 – Problema de Location Request entre Sites VOIP da Internet2 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á 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 BrasilAustralia, 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 Internet2 DGK Camberra GK UFRJ GK Telefone AARNET DGK Telefone PBX 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. 3.5.1 – Considerações sobre a Confiabilidade e Escalabilidade do Ambiente VOIP H.323 da UFRJ 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 h323gateway 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. 3.5.2 – Considerações sobre a Segurança do Ambiente VOIP H.323 da UFRJ 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 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 ma is 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 Transfer Facility to C A (em conversação) Call Transfer Setup to C B (em conversação) A (Transferindo) B (Gateway da Chamada) Call Transfer Facility Setup to C ANTES DO CALL TRANSFER C (Desligado) A (Desligado) B (em conversação) APÓS O CALL TRANSFER C (Transferido) C (em conversação) (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 Call Transfer Supplementary Service (H.450.2) Call Diversion Supplementary Service (H.450.3) Call Hold Supplementary Service (H. 450.4) Call Park and Call Pickup Supplementary Services (H.450.5) Call Waiting Supplementary Service (H.450.6) Message Waiting Indication Supplementary Service (H.450.7) Name Identification Supplementary Service (H.450.8) Call Completion Supplementary Services (H.450.9) Descrição Explicado no texto. Permite que, durante a fase de estabelecimento de chamada, seja desviada de uma chamada para outro terminal de destino. 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. 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. 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. 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. Permite que o usuário chamado veja o nome ou identificação do usuário chamador. 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) Call Intrusion Supplementary Service (H.450.11) Permite na requisição do usuário chamador que seja ofertado um tom de discagem para o usuário chamado quando ele estiver ocupado. 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). <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 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 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]. 4.2.1 – Mapeamentos entre o comportamento da CPL de SIP para H.323 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 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 Nós Incoming e Outgoing Significado Apêndice B do CPL Anexo O do H.323 Indica se o script CPL será Segundo o Apêndice Quando o nó for incoming, se o executado quando a chamada B do CPL não há nó address–switch estiver sendo foi encaminha para o dono do diferença destes nós utilizado, caso ele esteja com script ou partindo do dono do no ambiente SIP e parâmetro destination, usar o script. H.323. H.323 destCallSignalAddress Quadro 15 – Diferenças para os nós Incoming e Outgoing Nó CPL Nó AddressSwitch Significado Decisões baseadas em endereços presentes na requisição original. Parâmetro field (origin,destination) Apêndice B do CPL Anexo O do H.323 No H.323, o parâmetro origin Embora, mais do que um corresponde ao H323 simples Alias possa existir em SourceAddress contendo vários uma mensagem H.323. A opção alias addresses. Deve-se adotar obrigatória da escolha alias uma política de prioridade, caso dentro de um número de múltiplos aliases estiverem possibilidade limita os sistemas presentes. H.323 Quadro 16 – Diferenças para os nós Address-Switch contendo parâmetro field Nó CPL Nó AddressSwitch Significado Decisões baseadas em endereços presentes na requisição original. Parâmetro subfield (alias-type) Nó CPL Nó StrinSwitch Significado Decisões baseadas em quaisquer informações textuais presentes na requisição da chamada. Parâmetro field: (subject, organization, user-agent, language e display) Apêndice B do CPL 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. Anexo O do H.323 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 Apêndice B do CPL Anexo O do H.323 No H.323, o nó string-switch Nada é definido com relação a com o parâmetro language isso. 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. Quadro 18 – Diferenças para os nós String-Switch contendo parâmetro field 74 Nó CPL Nó Location Significado Especificam localização a ser usada para o redirecionamento. Parâmetro url Nó CPL Nó Lookup Significado Especificam meios externos para buscar locations para o redirecionamento Apêndice B do CPL Location no H.323 deve ser especificado como H.323 urlid. Também seria possível o uso de outros alias-types desde que tenhamos esta extensão CPL. Anexo O do H.323 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 Apêndice B do CPL Anexo O do H.323 Os nós de lookup, fazem uma O nó lookup é um conceito busca dos registros independente de sinalização, correspondentes ao location mas no caso do SIP, o lookup que estejam registrados no pode ser feito com outros servidor GK de uma Zona parâmetros de filtragem, por Administrativa usando exemplo, por capacidades. O mensagens RAS. 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. 4.3.1 – Gerenciamento da Parte Gráfica do Editor CPL 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). 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. 4.3.2 – Gerenciamento da Parte de Manipulação XML 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 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, preenc hendo 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 CPLXML. 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]. 4.3.3 – Utilizando Serviço Web para Gatekeeper 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 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 sua s 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). 4.4.1 – Módulo de Manipulação CPL-XML do Servidor 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. 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. 4.4.2 – Exemplo da Execução de Script CPL pelo Servidor 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 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 <?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 <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. 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. ARQ destinationInfo cesar Terminal H.323 aguiar submetendo cesar.cpl numa etapa anterior Server Gatekeeper CPL-Aware Terminal H.323 cesar <cpl> <incoming> CPLElement. next( ) cesar.cpl <address-switch ...> ... <otherwise> </location url="voicemail> <redirect> ACF destCallSignalAddress IP do voicemail RasServer. doACF (voicemail) OpenH323 Answering Machine voicemail SETUP SETUP ARQ aguiar não tem script associado ACF CONNECT RTP/UDP FLOW 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. 4.4.3 – Impacto do CPL para a Escalabilidade do GK 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 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 trans missã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 tieline, 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 Recommendation TELECOMMUNICATION H.323: Packet-Based UNION Multimedia (ITU). 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 Recommendation H.323 UNION (ITU). 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 Trunk SYSTEMS. Network Digital Module. T1/E1 Disponível em: Packet Voice 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 Recommendation TELECOMMUNICATION H.225.0: Media Stream UNION Packetization (ITU). 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 Recommendation TELECOMMUNICATION X.680: Abstract Syntax UNION Notation One (ITU). (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 SIP User Agent SIP Proxy Server SIP Redirect Server SIP Registrar Server Servidor de Localização Função Cliente da arquitetura, ou o ponto final da comunicação multimídia. 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. 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. Servidor SIP que suporta requisições REGISTER, usadas para registrar as informações dos usuários em algum 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 Método INVITE ACK OPTIONS BYE CANCEL REGISTER do Comportamento 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]. 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. 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. Usado para liberar os recursos associados a uma ligação e forçar a desconexão da mesma. 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. 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) (2) (3) (4) (5) (6) (7) (8) Usuário bruno pede para ser criada uma sessão entre ele e o usuário de "alias" [email protected]. [Requisição SIP INVITE] 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]. 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). 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 [RINGRING]. 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]. O servidor proxy redireciona essa resposta ao cliente chamador [Resposta de Sucesso 200 OK redirecionada para bruno]. 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]. 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 Terminais H.323 Gatekeeper MCU Gateway PSTN Border Element Função São os clientes da arquitetura, ou ponto finais da comunicação. 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). Possui funções de controle para suporte a conferências entre três ou mais pontos terminais em uma conferência multiponto. 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). 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 Ackno wledge (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.