Universidade Católica de Brasília Curso de Ciência da Computação Projeto Final. Monografia MAM VIDEOCONFERÊNCIA

Transcrição

1 Universidade Católica de Brasília Curso de Ciência da Computação Projeto Final Monografia MAM VIDEOCONFERÊNCIA Alunos: Artur Queiroz Teixeira 97/ Marcos Sanmartin de Mello 97/ Marcos Vinícius de Oliveira 97/ Orientador: Mauro Tapajós Santos Brasília, DF - Novembro / 2002

2 Universidade Católica de Brasília Curso de Ciência da Computação Projeto Final Monografia VIDEOCONFERÊNCIA Alunos: Artur Queiroz Teixeira 97/ Marcos Sanmartin de Mello 97/ Marcos Vinícius de Oliveira 97/ Orientador: Mauro Tapajós Santos Brasília, DF - Novembro / 2002

3 AGRADECIMENTOS Agradecemos a nossos pais e mestres pela força e estímulo para alcançar nossos objetivos. O orientador foi, também, de grande ajuda para tornar possível a implementação deste estudo e agradecemos, por fim, a Universidade Católica de Brasília por todos esses anos de um serviço de ensino a que nos foi prestado e que foi de grande validade para projetos que implementamos e iremos implementar no futuro.

4 Projeto Final de Graduação, sob a Orientação do Prof. Mauro Tapajós Santos, avaliado por uma Banca Examinadora do Curso de BCC da UCB e constituiu requisito para obtenção do Título de Bacharel em Ciências da Computação.

5 SINOPSE Este projeto apresenta um estudo detalhado dos componentes necessários a uma videoconferência sobre redes baseadas em pacotes e a análise de cenários práticos. Este estudo consiste em identificar os protocolos participantes de uma videoconferência, conceituando-os e detalhando as trocas de mensagens necessárias ao funcionamento destes protocolos. Incluído neste projeto está a análise das mensagens trocadas desde o estabelecimento até o encerramento de uma chamada entre elementos de uma rede de videoconferência em alguns cenários específicos. Além disso, a identificação das limitações dos protocolos e de alguns softwares utilizados nos cenários, também faz parte do trabalho. Como resultado, foi possível estabelecer e validar um conjunto mínimo de parâmetros que poderá ajudar quem deseja realizar videoconferência sobre redes baseadas em pacotes.

6 ABSTRACT This project aims to present a specified study of the necessary components of a videoconference over packet-based network and scenarios analyses. This study consists on the identification of the participating protocols in a videoconference, the evaluation of them and the specification of the trade of messages that occur to make them work. It is included in this project the trade of messages analyses on establishment of a call until the end of it in specific scenarios. Furthermore, the protocols and softwares limitations identification is within this paper. As a result, it was possible to establish and validate a minimum set of parameters, which can help everyone that want to communicate using videoconference over packet-based networks.

7 ÍNDICE ANALÍTICO 1 Introdução Objetivos da Pesquisa Cronograma Cronograma Previsto Cronograma Realizado Acrônimos Padrões de Videoconferência sobre redes de pacotes Padrão H Componentes do Padrão H Terminais Gateways Gatekeeper MCU Protocolos do Padrão H RTP e RTCP H225 ou RAS Q H H T H Audio Codec Vídeo Codec SIP Mensagens SIP Mensagens de Requisição (Request) Mensagens de Resposta (Response) Autenticação MGCP O Modelo MGCP Arquitetura e Entidades MGCP Protocolo MGCP Relacionamento entre MGCP, SIP e H Telefonia IP Voz sobre IP Ambiente de Telefonia IP Ambiente de Validação Aplicativos Utilizados Netmeeting OpenH

8 OpenMCU OpenGK OpenPhone GnomeMeeting Sniffer Ethereal CallFlow Análise Prática Cenário Cenário Cenário Cenário Cenário Cenário Dificuldades Participantes Instituição Orientador Implementação Conclusão Bibliografia

9 1 Introdução Estamos diante de um mundo totalmente globalizado, onde a distância não significa mais o que significava há alguns anos atrás. Antigamente quando queríamos encontrar alguém, ou até mesmo se comunicar com alguém que estivesse a míseros dois quilômetros de distância, era uma dificuldade. Surgiram então as cartas. As pessoas que sentiam necessidade de se comunicarem com outras que se localizavam em outra cidade, podiam enviar cartas através dos correios. As cartas demoravam um pouco para chegarem e muitas vezes as cartas, quando chegavam em seu destino, já não refletiam a realidade do momento. Mesmo com o surgimento do telefone, muitos problemas ainda continuaram sem solução como, por exemplo, a impossibilidade de troca de documentos e visualização da pessoa com quem conversávamos. A internet veio como uma ferramenta de aproximação entre as pessoas interligando o planeta e tornando possível a troca de informações entre pessoas de todos os países, nacionalidades e culturas. As pessoas passaram e se comunicar com muito mais eficiência e velocidade minimizando, assim, o problema da distância. As cartas foram, em grande parte, substituídas pelos s que possibilitam o envio de qualquer tipo de material escrito como documentos e cartas pessoais. Mesmo com todos esses avanços, ainda existia a necessidade de se comunicar com as pessoas sem que fosse notada a distância entre elas, tornando possível a comunicação em tempo real. Um exemplo é as empresas que possuem filiais em cidades diferentes e precisam fazer inúmeras reuniões e, conseqüentemente, inúmeras viagens. Todas essas necessidades levaram a criação de uma tecnologia que permitisse troca de voz, dados e vídeo entre duas ou mais pessoas em tempo real. Porém, esta tecnologia, chamada de Videoconferência, requer uma rede confiável e veloz para a transmissão de informações. No início eram necessários hardwares e redes robustas que suportavam grandes fluxos de dados. Eram necessários canais dedicados com alta largura de banda, tornando toda essa implementação algo caro e complexo. 8 / 123

10 Houve então a necessidade de tornar o processo de videoconferência algo viável e barato para que pudesse ser utilizado tanto por grandes empresas como também por usuários de computadores pessoais. Surgiu então a videoconferência sobre redes baseadas em pacotes que é o padrão da internet e está ao alcance de todos. Com esta inovação, várias empresas se atiraram no mercado a fim de implementar e tornar possível o que antes era apenas um sonho. Após o surgimento de alguns programas que implementavam a videoconferência sobre redes de pacotes, foi observado que estes programas não eram compatíveis entre si. Surgiu então a necessidade da criação de um padrão que fosse seguido por todas as empresas que quisessem implementar algo relacionado com videoconferência, e assim, tornar possível esta compatibilidade. Duas organizações de padronização, a IETF (padrão da Internet) e a ITU-T (padrão de Telecomunicações) criaram, cada uma, um padrão para se implementar videoconferência sobre redes baseadas em pacotes. Em 1996, a ITU-T criou o padrão H323 que utiliza vários protocolos para realização de conferências de áudio e vídeo, sendo hoje o padrão mais utilizado e difundido no mundo. Os principais software de videoconferência, por exemplo, Netmeeting e Gnomemeeting utilizam este padrão para realizar o controle de sinalização e a troca de informações entre usuários. A IETF criou o SIP que é um protocolo de sinalização utilizado para chamadas telefônicas pela internet, conferências multimídia, sessões de chat e comunicação interativa. Este protocolo é ainda muito recente, sendo os primeiro estudos realizados na Universidade de Columbia em setembro de A Videoconferência pode ser definida como uma comunicação simultânea e em tempo real entre duas ou mais pessoas na qual os participantes vêem e ouvem uns aos outros através de monitores, caixas de som, microfones e câmeras, apesar de não estarem no mesmo local físico. Este tipo de comunicação pode significar economia de tempo e dinheiro, pois evita muitas viagens desnecessárias. Um aspecto interessante da videoconferência é a possibilidade que os participantes têm de compartilhar arquivos, tornando assim a videoconferência uma simulação perfeita de uma 9 / 123

11 reunião tradicional. Portanto, em uma videoconferência é possível se trocar qualquer tipo de informação disponível hoje, podendo ser áudio, vídeo e/ou dados. Porém, é preciso ressaltar um fator importantíssimo no fluxo multimídia. As informações de áudio e vídeo necessitam de uma certa qualidade de serviço de rede para que possam trafegar sem sofrerem danos sobre redes de pacotes, os quais possam comprometer sua qualidade e até sua inteligibilidade. Essa qualidade de serviço é oferecida em redes baseadas em circuitos ou circuitos virtuais como, por exemplo, uma rede ISDN (Integrated Services Digital Network) ou uma rede ATM (Asynchronous Transfer Mode). Desse modo as redes baseadas em pacotes, por não oferecerem qualidade de serviço, precisam de outros mecanismos para poderem suportar fluxos multimídia. Como hoje em dia a maioria das redes do mundo são redes IP (Internet Protocol), inclusive a internet, seria muito útil um sistema de videoconferência que pudesse ser utilizado em todas estas redes. Neste sentido foram criados alguns tipos de sistemas de videoconferência que provêem gerenciamento, controle e garantia de segurança necessários à transmissão de áudio e vídeo. Por ser uma área de muito crescimento nos últimos anos e bastante promissora, escolhemos a videoconferência sobre IP como nosso objeto de pesquisa. Para sermos mais precisos, delimitamos os protocolos do padrão H323 da ITU-T, SIP da IETF e MGCP da Nortel Networks como nosso universo de pesquisa. Estes padrões de videoconferência foram escolhidos por nós, porque são os mais difundidos no mundo hoje. 10 / 123

12 2 Objetivos da Pesquisa O objetivo deste projeto é analisar os padrões de videoconferência, principalmente o padrão H323 da ITU-T, explicando os vários protocolos necessários para cada padrão. Para cada protocolo serão analisadas sua utilidade e sua eficiência. Serão também identificadas e detalhadamente analisadas as mensagens trocadas entre os diversos componentes de uma videoconferência. Além disso, o projeto inclui a pesquisa de ferramentas freeware para a implementação de cenários específicos. A pesquisa de ferramentas free é de grande importância devido ao alto custo de ferramentas mais modernas. Será feita a análise dos testes realizados com as ferramentas nestes cenários, identificando as capacidades e limitações destas ferramentas e dos protocolos participantes na realização de videoconferências. Inclui-se nesta análise a qualidade do vídeo e do áudio recebido e/ou enviado por cada um e a capacidade de suportar usuários simultâneos. 11 / 123

13 3 Cronograma O cronograma foi dividido em duas partes, o Cronograma Previsto, que é uma previsão dos esforços a serem realizados para alcançar os objetivos, e o Cronograma Realizado que é o tempo real que levamos para atingir os objetivos esperados. 3.1 Cronograma Previsto ATIVIDADES AGO SET OUT NOV 1. Definição dos requisitos e objetivos do projeto 2. Pesquisa sobre os assuntos do projeto 3. Aplicação da parte teórica com a prática de testes 4. Análise dos resultados obtidos 5. Considerações finais da monografia 6. Preparação da apresentação 3.2 Cronograma Realizado ATIVIDADES AGO SET OUT NOV 1. Definição dos requisitos e objetivos do projeto 2. Pesquisa sobre os assuntos do projeto 3. Aplicação da parte teórica com a prática de testes 4. Análise dos resultados obtidos 5. Considerações finais da monografia 6. Preparação da apresentação 12 / 123

14 4 Acrônimos ATM CIF CNAME FDDI HTTP IETF IP ISDN ITU-T LAN MC MCU MG MGC MGCP MOS MP OSI P2P PSTN QOS RAS RTCP RTP RTPC SDP SDU SIP Asynchronous Transfer Mode Common Interchange Format Canonical Name Fiber Distributed Data Interface Hypertext Transfer Protocol Internet Engineering Task Force Internet Protocol Integrated Services Digital Network International Telecomunication Union Local Area Network Multipoint Controller Multipoint Control Unit Media Gateway Media Gateway Controller Media Gateway Control Protocol Mean Opinion Score Multipoint Processor Open Systems Interconnection Peer-to-Peer Public Switched Telephone Network Quality of Service Registration, Administration and Status Real Time Control Protocol Real Time Protocol Rede Telefônica Pública Comutada Session Description Protocol Service Data Unit Session Initiation Protocol 13 / 123

15 SMTP TCP UDP VOIP Simple Main Transfer Protocol Transmission Control Protocol User Datagram Prococol Voice Over IP 5 Padrões de Videoconferência sobre redes de pacotes e o MGCP. Hoje os principais padrões de videoconferência sobre redes IP são: o padrão H323, o SIP 5.1 Padrão H323 O padrão H323 é uma recomendação da ITU-T que especifica sistemas de comunicação multimídia em redes baseadas em pacotes, as quais não oferecem qualidade de serviço. Isso permite a utilização de aplicações multimídia sem necessitar de mudanças nas redes. Dentro desta recomendação são estabelecidos padrões de codificação e decodificação de fluxos de áudio, vídeo e dados e sinalização; o que garante uma interoperabilidade entre produtos de vários fabricantes. Além disso, o padrão H323 é totalmente independente de tecnologia de rede (Ethernet, FDDI, Token Ring), topologia de rede (LAN, Internet), hardware e sistema operacional; e tem também suporte multicast para conferências multiponto.um outro ponto positivo deste padrão é que as aplicações clientes não precisam ter a mesma capacidade multimídia, ou seja, uma aplicação que suporta apenas áudio pode participar de conferências com terminais que suportam áudio e vídeo. Observando estas vantagens, grandes empresas como IBM, Intel, CISCO e Microsoft estão produzindo equipamentos e aplicações baseados neste padrão. 14 / 123

16 5.1.1 Componentes do Padrão H323 A recomendação da ITU-T para o padrão H.323 define 4 componentes principais para um sistema de videoconferência: Terminais, Gateways, Gatekeepers e Multipoint Control Units (MCU). Estes componentes estão representados na figura 1. Figura 1 - Arquitetura de um sistema H Terminais Os Terminais são dispositivos que possuem aplicações multimídia, as quais suportam pelo menos fluxo de áudio Gateways 15 / 123

17 Um Gateway provê tradução de protocolos para conexão e desconexão, conversão de formatos de media entre redes diferentes e transferência de informação entre redes que suportam o padrão H.323 e redes que não suportam de acordo com a figura 2. Figura 2 - Serviços oferecidos pelo Gateway Do lado da rede que suporta o padrão H.323, um Gateway executa a sinalização de controle do H.245 para a troca de capacidades, a sinalização de conexão e desconexão do H.225 e os registros, admissões e status pra registro no Gatekeeper. Os terminais se comunicam com os Gateways usando o controle de sinalização do protocolo H.245 e o controle de chamadas do protocolo H.225. O Gateway traduz todos esses protocolos de uma forma totalmente transparente para seus respectivos componentes da rede que não suporta o padrão H.323 e vice versa. O Gateway também executa call setup e clearing tanto na rede que suporta H.323 quanto na que não suporta. Conversão de áudio, vídeo e dados também podem ser feitos pelo Gateway. Conversão de áudio e vídeo pode não ser necessária se os dois terminais encontrarem uma forma comum de se comunicarem. Os Gatekeepers estão sempre atentos a quais elementos da rede são Gateways, pois isto é indicado quando tanto o Terminal quanto o Gateway fazem seus registros no Gatekeeper. Um Gateway deve suportar um número considerável de chamadas simultâneas entre a rede H.323 e a rede não H.323. O Gateway é um componente lógico do H.323 e pode ser implementado como parte do Gatekeeper ou da MCU. 16 / 123

18 Gatekeeper Os Gatekeepers provêm serviços de controle de chamadas para Terminais H.323 tais como conversão de endereços e gerenciamento de largura de banda. Nas redes H.323, os Gatekeepers são opcionais. Se eles estiverem presentes na rede, tanto os Terminais quanto os Gateways precisam usar seus serviços. O padrão H.323 define como obrigatório para o Gatekeeper prover serviços para os Terminais e os Gateways. Existem também serviços opcionais que podem ou não ser disponibilizados. Um dos serviços opcionais do Gatekeeper é o roteamento de chamadas sinalizadas. Os Terminais fazem chamadas sinalizadas para o Gatekeeper e este roteia para o Terminal de destino. Também é possível que um Terminal chame outro diretamente, sem passar pelo Gatekeeper. Este serviço do Gatekeeper é de grande valor pois torna possível o monitoramento de chamadas provendo assim um melhor controle das chamadas dentro da rede. Roteando as mensagens pelo Gatekeeper melhora a performance da rede com um todo pois a rede passa a ter a inteligência de escolher melhores rotas para suas chamadas. O Gatekeeper é um componente opcional nos sistemas que implementam o padrão H.323. Os serviços oferecidos por este componente é definido pela RAS (Registration, Admission and Status) e estão incluídos os serviços de tradução de endereços, controle de admissões, controle de largura de banda e gerenciamento de zona como mostra a figura 3. Sistemas de videoconferência que não implementam Gatekeepers não têm todas essas capacidades. 17 / 123

19 Figura 3 - Serviços oferecidos pelo Gatekeeper As funções obrigatórias de um Gatekeeper são: Tradução de endereços: Chamadas originadas de dentro de uma rede que implementa o padrão H.323 podem usar uma espécie de alias para endereçar o Terminal de destino. Chamadas originadas de fora da rede H.323 e recebidas pelo Gateway deve usar um número no padrão E.164 para endereçar o Terminal de destino. O Gatekeeper traduz esse número ou o alias em um endereço de rede válido do Terminal de destino. Controle de Admissão: O Gatekeeper pode controlar o nível de admissão dos Terminais dentro da rede H.323. Ele usa mensagens RAS para tornar possível este controle de admissão. É possível também configurar este controle para que aceite qualquer chamada de qualquer Terminal, ou seja, sem nenhum controle de admissão. Controle de Largura de Banda: O Gatekeeper provê suporte para controle de largura de banda usando mensagens RAS. Por exemplo, Caso um gerente de rede tenha especificado um máximo de conexões simultâneas na rede H.323, O 18 / 123

20 Gatekeeper pode recusar a fazer mais conexões se o limite de conexões for alcançado. O resultado é a limitação da largura de banda disponível em uma fração desta largura mantendo o que sobrou da largura para outras aplicações. O controle de largura de banda pode também ser desligado deixando assim que todos os pedidos de conexões sejam aceitos. Gerenciamento de Zona: O Gatekeeper suporta as funções descritas acima para Terminais, Gateways e MCU alocadas dentro da zona de controle As funções opcionais de um Gatekeeper são: sinalização de chamadas, autorização de chamadas e gerenciamento de chamadas. Sinalização de Chamadas: O Gatekeeper pode rotear mensagens de sinalização de chamadas entre os Terminais que estão na rede H.323. Em uma conferência ponto-a-ponto, o Gatekeeper pode processar Mensagens H.225 de sinalização de chamadas. Além disso, o Gatekeeper pode permitir que os próprios Terminais enviem mensagens H.225 de sinalização de chamadas diretamente para os Terminais de destino. Autorização de Chamadas: Quando um Terminal envia uma mensagem de sinalização de chamada para o Gatekeeper, O Gatekeeper pode aceitar ou recusar a chamada, de acordo com as especificações H.225. Uma razão que pode levar o Gatekeeper a rejeitar uma chamada pode ser restrições quanto ao acesso para ou de alguns Terminais particulares ou até mesmo de Gateways. Gerenciamento de Chamadas: O Gatekeeper pode manter informações sobre todas as chamadas H.323 ativas e assim ele pode controlar sua zona provendo informações relevantes para as funcionalidades de gerenciamento de largura de banda e roteamento de chamadas para diferentes Terminais. 19 / 123

21 MCU Para participar de uma chamada ponto-a-ponto, os participantes simplesmente fazem uma chamada para um endereço IP da rede e a chamada é inicializada, como numa chamada telefônica comum. Se for preciso fazer uma videoconferência com mais de duas pessoas, o modelo ponto-aponto não irá atender e a partir desta necessidade foi criada a Multipoint Control Unit (MCU). Antigamente, era necessário fazer uma chamada para um número especial para se conectar a uma MCU. Além disso, esses sistemas permitiam que o participante visualizasse somente um participante por vez, normalmente aquele que estivesse falando no momento não importando assim quantas pessoas estivessem conectadas. Sistemas mais modernos permitem a visualização de vários participantes ao mesmo tempo. MCU mais modernas mudaram a visão que se tinha da videoconferência pois eliminaram a necessidade de agendar e pagar por um espaço na MCU. A MCU sobre o padrão H.323 consiste em pelo menos um Multipoint Controller (MC) e nenhum ou mais Multipoint Processors (MP). O MC lida com as negociações H.245 entre todos os terminais para determinar uma capacidade comum para processamento de áudio e vídeo. Já o MP provê mixagem, switching e qualquer outro tipo de processamento de pacotes que for necessário. Sem o uso da MCU, limitamos nossa videoconferência ao caso ponto-a-ponto onde somente duas pessoas podem se comunicar simultaneamente. Alguns softwares permitem que exista comunicações simultâneas, mas nunca será possível ver todos os participantes ao mesmo tempo, seria necessário alternar entre os participantes, ou seja, este sistema teria várias conexões ponto-a-ponto. Com a implementação da MCU, podemos conversar com todos os participantes ao mesmo tempo, ver o vídeo de todos eles ao mesmo tempo. A MCU foi um grande avanço na tecnologia de videoconferência. 20 / 123

22 5.1.2 Protocolos do Padrão H323 A recomendação da ITU-T para o padrão H323 especifica que o transporte de áudio e vídeo deve ser feito sobre UDP utilizando o protocolo RTP/RTCP. O RTP (Real-Time Protocol) insere no pacote UDP informações de tempo e seqüência que permite o sincronismo entre áudio e vídeo. O RTCP (Real-Time Control Protocol) é o protocolo que monitora a qualidade do serviço prestado pelo RTP. Os protocolos de sinalização do padrão H323 utilizam o TCP, pois os serviços de controle e de transferência de dados precisam ser confiáveis. Os protocolos de sinalização utilizados pelo padrão H323 são: H225 ou RAS (Registration Admission and Status) que cuida do registro, da administração e do Status; Q931 que gerencia o inicio e o fim da chamada; H245 que negocia o uso dos canais e as respectivas capacidades. Outros protocolos são usados para estender as funcionalidades do padrão H323. Estes protocolos são os seguintes: H235 que cuida da segurança e autenticação; T120 que trata da transferência de dados durante uma chamada Multimídia; H450 que traz adaptações da telefonia IP para o padrão H323. A recomendação ITU-T para o padrão H323 especifica que o terminal deve ser capaz de codificar e decodificar áudio utilizando o codec G711 e vídeo utilizando o codec H261, sendo os outros codecs opcionais em um sistema H323. Os codecs que podem ser utilizados segundo o padrão H323 são: Audio codec o G PCM audio codec para 56/64 kbps 21 / 123

23 o G.722 audio codec para 48, 56 e 64kbps o G audio codec para 5.3 e 6.3 kbps o G audio codec para 32 kbps o G audio codec para 16 kbps o G audio codec para 8/13 kbps o GSM - audio codec para 8 kbps Video codec o H video codec para >= 64kbps o H video codec para < 64kbps RTP e RTCP O RTP é um protocolo padrão para transporte de dados com características de tempo real, como vídeo e áudio, que pode ser usado em diferentes serviços como mídia sob demanda e interativos. O protocolo é composto por uma parte de transmissão de dados e outra de controle, chamada RTCP. A parte de dados consiste de um protocolo leve, que provê suporte para aplicações com características de tempo real, incluindo reconstrução temporal de mensagens, detecção de perdas, segurança, selo de tempo e identificação de conteúdo. O protocolo de transporte envolve: acompanhar o fluxo de bits gerados pelo codificador de mídia, normalmente a telefonia IP, quebrando em pacotes, enviando-os pela rede e reproduzindo o fluxo de bits no receptor. O processo é complexo porque os pacotes podem ser perdidos, podem sofrer atrasos variados e serem entregues fora de ordem. O protocolo de transporte deve permitir ao receptor detectar estas perdas. Ele deve também transportar informações de temporização de forma que o receptor possa fazer também compensação para o atraso. 22 / 123

24 Algumas funcionalidades do RTP são: seqüenciamento, sincronismo intramídia, identificação de conteúdo, identificação de quadro, identificação de origem. Já o RCTP, que acompanha o RTP, provê informações adicionais sobre seus participantes, tais como retorno de informações de qualidade de serviço, sincronismo intermídia e identificação do usuário. O RTCP necessita que todos os participantes enviem estas informações periodicamente. O protocolo usa o mesmo endereço do RTP, porém em porta diferente. Nem todas as aplicações RTP utilizam o RTCP, ou seja, pode ser dispensável para algumas aplicações. Aplicações em tempo real, tais como VoIP e fluxo de vídeo, têm um número de requisitos que as distinguem dos serviços de dados tradicionais da Internet: Seqüência: os pacotes devem ser reordenados em tempo real no receptor, caso eles cheguem fora de ordem. Se um pacote é perdido, ele deve ser detectado e compensado sem retransmissão; Sincronização intra-mídia: o intervalo de tempo que existe entre pacotes sucessivos deve ser transmitido ao receptor como informação de controle. Por exemplo, nenhum dado é geralmente enviado durante períodos de silêncio na fala. A duração desse silêncio deve ser reconstruída adequadamente. Se um número de diferentes mídias estão sendo usadas em uma única sessão, devem haver meios de sincronizá-las. Com isso, é possível sincronizar o sinal de voz com o de vídeo. Isso também é conhecido como lip-sync; Identificação do payload: na Internet, freqüentemente é necessário modificar a taxa de transmissão dinamicamente para ajustar-se à disponibilidade de largura de faixa ou a novos usuários que se juntam ao grupo. Algum tipo de mecanismo é necessário para identificar a codificação utilizada em cada pacote; Identificação de frame: vídeo e voz são enviados em unidades lógicas chamadas frames. É necessário indicar para o receptor onde é o inicio ou fim do frame, de forma a auxiliar no sincronismo da entrega dos dados. 23 / 123

25 O RTP é geralmente usado em conjunto com o UDP, mas pode fazer uso de qualquer protocolo de nível inferior baseado em pacotes. Quando um host deseja enviar um pacote de mídia, formata-o para empacotamento, adiciona qualquer cabeçalho específico, adiciona o cabeçalho RTP, e o passa para a carga de um nível mais baixo. O RTP fornece algumas funcionalidades que vão além de reseqüenciamento de detecção de perda: Multicast-friendly: O RTP e o RTCP foram projetados para multicast. De fato, eles foram projetados para desde pequenos grupos muticast, como aqueles usados em uma ligação telefônica compartilhada por três pessoas, até para muitas pessoas. Como em eventos broadcast; Independência da mídia: O RTP fornece serviços à mídia de tempo real genéricas, tais como voz e vídeo. Os cabeçalhos e semânticas de qualquer codificação específica são definidos para cada mídia em especificações separadas; Mixers e Traslators: Os Mixers são dispositivos que pegam mídias de vários usuários, as misturam e enviam o fluxo resultante. Os Translators pegam um único fluxo de mídia, converte-o para outro formato envia-o; Retorno da QoS: O RTCP permite aos receptores fornecer um retorno a todos os membros de um grupo, enviando informações sobre a qualidade da recepção. As fontes RTP podem usar essa informação para ajustar a sua taxa de comunicação, enquanto que outros receptores podem determinar se os problemas na qualidade do serviço são locais ou gerais. Observadores podem usar essa informação para o gerenciamento da QoS; Controle de sessão livre: Com o RTCP, os participantes podem trocar informações de identificação tais como nome, , número telefônico, e mensagens breves; Criptografia: Os fluxos de mídia RTP podem ser criptografados usando-se chaves que são trocadas por algum método não RTP. 24 / 123

26 O RTP tem dois componentes: o primeiro é o próprio RTP, e o segundo é o RTCP. O RTCP é o protocolo de controle auxiliar do RTP. Os transmissores e receptores de mídia periodicamente enviam pacotes RTCP para o mesmo grupo multicast (mas em diferentes portas) usado para distribuir os pacotes RTP. Cada pacote RTCP contém um número de elementos, geralmente um relatório do transmissor (SR) ou um relatório do receptor (RR) seguido de descrição de fonte (SDES). Cada um serve para uma função diferente: Relatório do transmissor (SR): são gerados pelo usuário que estão também enviando mídia (fontes RTP). Eles descrevem a quantidade de dados enviados até o momento, bem como correlacionam o timestamp amostrado do RTP com o tempo absoluto para permitir a sincronização entre mídias diferentes; Relatórios do receptor (RR): são enviados pelos participantes da sessão RTP que estão recebendo mídia. Cada um desses relatórios contém um bloco para cada fonte RTP no grupo. Cada bloco descreve a taxa de perda dessa fonte. O bloco também indica o último timestamp e o atraso desde o último relatório do transmissor recebido, permitindo que as fontes estimem suas distâncias aos receptores; Descrição de fonte (SDES): são pacotes usados para controle de sessão. Eles contém Canonical Name (CNAME), um identificador único global similar em formato a um endereço de . O CNAME é usado para associar diferentes fluxos de mídia gerados pelo mesmo usuário. Os pacotes SDES também identificam o participante através de seu nome, e número telefônico. Isso fornece uma forma simples de controle da sessão. As aplicações clientes podem mostrar as informações de nome e na interface do usuário. Isso possibilita aos participantes da sessão saber mais sobre os outros participantes.se um usuário está saindo, ele inclui a mensagem BYE. Finalmente, elementos de aplicação (APP) podem ser usados para adicionar informações específicas da aplicação nos pacotes RTCP. Desde que o relatório do transmissor, os relatórios do receptor e os pacotes SDES contêm informações que podem mudar continuamente, é necessário enviar esses pacotes periodicamente. 25 / 123

27 Se os participantes de uma sessão RTP simplesmente enviam pacotes RTCP em um período fixo, a largura de faixa usada em um grupo multicast poderia crescer linearmente com o tamanho do grupo, o que é indesejável. Ao invés disso, cada membro da sessão conta o número de outros membros da sessão que ele ouve (através de pacotes RTCP). O período entre pacotes RTCP para cada usuário é então ajustado para ser linearmente escalonado com o número de membros do grupo H225 ou RAS O protocolo H225, segundo a recomendação da ITU-T, tem dois objetivos. Caso não exista um Gatekeeper na rede, o H225 trabalhará em conjunto com o Q931 especificando a maneira com que os terminais se comunicaram para efeito de inicialização e encerramento de chamadas. Porém, se existir um Gatekeeper na rede, então o H225 definirá as mensagens RAS (Registration, Administration and Status) que serão usadas para a comunicação entre o Gatekeeper e os demais elementos da rede. Neste caso o Gatekeeper pode estar roteando as mensagens de sinalização ou não as roteando, como mostra a figura 4 e a figura 5. Gatekeeper 1 - ARQ 2 - ACF/ARJ 3 - Setup 4 - ARQ 5 - ACF/ARJ 6 - Connect Terminal 1 6 Terminal 2 Figura 4 Gatekeeper não roteando as mensagens de sinalização 26 / 123

28 Gatekeeper ARQ 2 - ACF/ARJ 3 - Setup 4 - Setup 5 - ARQ 6 - ACF/ARJ 7 - Connect 8 - Connect Terminal 1 Terminal 2 Figura 5 Gatekeeper roteando as mensagens de sinalização As mensagens RAS utilizadas no padrão H323 trocadas entre o Gatekeeper e os demais elementos da rede são: GatekeeperRequest (GRQ): é enviada pelo terminal aos demais elementos da rede perguntando qual a localização do Gatekeeper. GatekeeperConfirm (GCF): é uma resposta à mensagem GRQ informando o endereço IP e a porta de espera do Gatekeeper. GatekeeperReject (GRJ): é uma resposta à mensagem GRQ informando o motivo da rejeição de informar a localização do Gatekeeper. RegistrationRequest (RRQ): é enviada ao Gatekeeper por outro elemento da rede pedindo seu registro, ficando assim sobre o controle do respectivo Gatekeeper. Este registro é necessário ser aceito pelo Gatekeeper para que qualquer outra mensagem seja trocada entre eles. RegistrationConfirm (RCF): é uma resposta à mensagem RRQ confirmando o registro no Gatekeeper. RegistrationReject (RRJ): é uma resposta à mensagem RRQ rejeitando o registro no Gatekeeper. 27 / 123

29 AdmissionRequest (ARQ): é uma mensagem enviada para um Gatekeeper de um elemento da rede já registrado pedindo o estabelecimento de uma chamada. Pode ser para iniciar uma chamada ou para participar de uma chamada já existente entre outros terminais.o Gatekeeper formula sua resposta baseado em alguns fatores como disponibilidade de banda na rede. AdmissionConfirm (ACF): é uma resposta à mensagem ARQ aceitando o estabelecimento de uma chamada. AdmissionReject (ARJ): é uma resposta à mensagem ARQ rejeitando o estabelecimento de uma chamada. DisengageRequest (DRQ): é uma mensagem enviada a um Gatekeeper por outro elemento da rede informando que uma chamada foi encerrada. Pode ser também enviada por um Gatekeeper a outro elemento da rede encerrando uma chamada. DisengageConfirm (DCF): é uma resposta à mensagem DRQ confirmando o encerramento da chamada. DisengageReject (DRJ): é uma resposta enviada por um Gatekeeper informando que o elemento da rede que o enviou a mensagem DRQ não está registrado. UnregistrationRequest (URQ): é uma mensagem enviada a um Gatekeeper por outro elemento da rede pedindo o cancelamento do registro no Gatekeeper. Pode ser também enviada por um Gatekeeper a outro elemento da rede cancelando seu registro. UnregistrationConfirm (UCF): é uma resposta à mensagem URQ confirmando o cancelamento do registro no Gatekeeper. UnregistrationReject (URJ): é uma resposta à mensagem URQ rejeitando o cancelamento do registro. 28 / 123

30 LocationRequest (LRQ): é uma mensagem enviada a um Gatekeeper pedindo o endereço IP de um elemento qualquer da rede. O Gatekeeper pode realizar esta tarefa através do seu serviço de tradução de endereços. LocationConfirm (LCF): é uma resposta à mensagem LRQ informando o endereço requisitado. LocationReject (LRJ): é uma resposta à mensagem LRQ rejeitando o envio do endereço requisitado. InfoRequest (IRQ): é uma mensagem enviada pelo Gatekeeper pedindo informações de status dos elementos da rede registrados nele. InfoRequestResponse (IRR): é uma resposta à mensagem IRQ enviando as informações de status Q931 Assim que a permissão para que um terminal participe de uma chamada for aceita, o protocolo Q931 cuidará da inicialização e do encerramento desta chamada. As mensagens de sinalização de chamadas do Q931 utilizadas pelo H323 são: Setup: é a mensagem usada para inicializar uma chamada, podendo ser comparada com a discagem de um número em uma chamada de telefone comum. CallProceeding: é a mensagem do receptor (é do Gatekeeper caso ele exista na rede) para o originador da chamada indicando que foi recebido o pedido de inicialização de chamada e este está sendo processado pelo terminal receptor. Alerting: é a mensagem que indica para o originador da chamada que o receptor está chamando, assim como um telefone comum. Connect: é a mensagem enviada pelo receptor aceitando a chamada. 29 / 123

31 ReleaseComplete: é a mensagem que indica que uma das partes deseja encerrar a chamada. Não é necessária uma mensagem de confirmação, porém algumas vezes ela é enviada. Progress: é uma mensagem do Gateway indicando o progresso da chamada. Esta mensagem pode também ser enviada por qualquer elemento da rede dependendo dos serviços suplementares implementados na rede. Facility: é uma mensagem enviada por um elemento da rede informando para onde a chamada deve ser direcionada ou informando que certa chamada deve passar por determinado Gatekeeper. Esta mensagem também pode ser utilizada para requisitar ou aceitar serviços suplementares de acordo com a série de protocolos H450.x. A figura 6 ilustra a troca de mensagens para estabelecimento de chamadas sem Gatekeeper. As figuras 7 e 8 ilustram a troca de mensagens para estabelecimento de chamadas com Getekeeper. Terminal 1 Terminal 2 Setup(1) Call proceeding(2) Alerting(3) Connect(4) Figura 6 - Mensagens trocadas para estabelecer chamadas sem Gatekeeper 30 / 123

32 Terminal 1 Gatekeeper Terminal 2 ARQ(1) ACF/ARJ(2) Setup(3) Call proceeding(4) ARQ(5) ACF/ARJ(6) Alerting(7) Connect(8) Figura 7 Mensagens trocadas para estabelecer chamada (com Gatekeeper não roteando) Terminal 1 Gatekeeper Terminal 2 ARQ(1) ACF(2) Setup(3) Setup(4) Call Proceeding(5) Call Proceeding(5) ARQ(6) ACF/ARJ(7) Alerting(8) Connect(10) Alerting(8) Connect(9) Figura 8 Mensagens trocadas para estabelecer chamada (com Gatekeeper roteando) H / 123

33 Depois que dois elementos da rede iniciaram uma chamada e estão prontos para enviar e receber informações, eles precisam estabelecer os formatos de voz, vídeo e dados que serão trocados entre eles. Estas informações trafegarão em canais lógicos que serão estabelecidos pelo protocolo H245. Para estabelecer estes canais o protocolo troca informações que incluem a capacidade de recebimento, capacidade de transmissão e a sinalização do canal lógico. As mensagens do protocolo H245 utilizadas pelo padrão H323 são: Capability Exchange; Master Slave Determination; Logical Channel Signalling; Mode Request; Round Trip Delay Determination; Comandos; Indicações Capability Exchange A primeira coisa a ser feita para iniciar os canais lógicos é estabelecer as capacidades dos elementos da rede. As mensagens TerminalCapabilitySet e TerminalCapabilitySetAck são usadas para estabelecer as capacidades dos terminais, principalmente a versão dos protocolos e os codecs suportados. Para isso, cada terminal possui uma Tabela de Capacidades com todos os codecs que ele suporta. Os três campos existentes nesta tabela são: Número da entrada na Tabela de Capacidades: armazena o número da entrada na tabela, ou seja, cada vez que é inserida na tabela uma capacidade do terminal um número seqüencial é atribuído a ela. Este número pode variar de 1 a 256, indicando que um terminal pode ter até 256 capacidades diferentes. 32 / 123

34 Capacidade (RCV or XMIT or RCV and XMIT): é indicado se o codec é suportado para receber (RCV), transmitir (XMIT) ou receber e transmitir (RCV and XMIT). Descrição: armazena o nome de cada codec suportado pelo terminal. Número da Entrada Capacidade (RCV or XMIT or RCV and XMIT) Descrição 1 RCV and XMIT G RCV and XMIT H RCV G RCV and XMIT G.723 N Tabela I - Tabela de Capacidades De acordo com a tabela I, o terminal é capaz de receber e transmitir usando o codec G.728, H.263 e G.723. Porém, este terminal só pode receber e não transmitir usando o codec G711. Além da Tabela de Capacidades, cada terminal possui uma Tabela de Descrição das Capacidade. Esta tabela possui apenas dois campos: Número da entrada na Tabela de Descrição das Capacidades: armazena o número da entrada na tabela, ou seja, cada vez que são inseridas capacidades simultâneas do terminal é atribuído um número seqüencial a elas. Capacidades Simultâneas: possui a combinação de tarefas que o terminal pode realizar simultaneamente. Os números que se encontram entre {} fazem referência ao número de entrada na Tabela de Capacidades. Número da Entrada Capacidades Simultâneas 33 / 123

35 0 {1},{2} 1 {2},{2} 2 {3} 3 {1,4},{2} Tabela II - Tabela de Descrição de Capacidades A tabela II mostra que o terminal pode realizar as seguintes tarefas: Receber e transmitir um fluxo G.728 e, simultaneamente, receber e transmitir um fluxo H.263 (entrada 0); Receber e transmitir dois fluxos H.263 (entrada 1); Apenas receber um fluxo G.711 (entrada 2); Receber e transmitir um fluxo G.728 ou um fluxo G.723 enquanto simultaneamente recebe e transmite um fluxo H.263 (entrada 3). Com base nas Tabelas de Capacidades e de Descrição das Capacidades, o protocolo H245 preenche a mensagem TerminalCapabilitySet que é enviada com os seguintes parâmetros: ID: identificador do protocolo H245 utilizado; CT: Tabela de Capacidades; CD: Tabela de Descrição das Capacidades. Assim que o terminal remoto recebe a mensagem TerminalCapabilitySet ele retorna uma mensagem de confirmação chamada TerminalCapabilitySetAck, de acordo com a figura / 123

36 Figura 9 - Troca de mensagens Capability Exchange Master Slave Determination Para que os canais possam ser abertos o protocolo H245 precisa determinar uma máquina como master e outra como slave em uma chamada. Ele faz isso para resolver conflito entre entidades da rede; no caso, por exemplo, em que dois elementos da rede podem ser MC de uma videoconferência. As mensagens MasterSlaveDetermination e MasterSlaveDeterminationAck são utilizadas para determinar quem será o master e o slave. A mensagem MasterSlaveDetermination contém dois tipos de parâmetros: Terminal type (TT) Status determnation number (SDNUM). O TT é um número atribuído a cada elemento da rede e este número é definido de acordo com a capacidade multimídia que o terminal possui. Assim, quanto maior a capacidade de multimídia ele possuir, maior será seu TT. A tabela III mostra como é atribuído um TT a um elemento da rede. Entidade H323 TT Terminal Gateway Gatekeeper MCU Entidade sem MC Entidade com MC, mas sem MP / 123

37 Entidade com MC e MP de dados Entidade com MC e MP de dados e áudio Entidade com MC e MP de dados, audio e vídeo Tabela III - Valor do TT para cada entidade da rede Já o SDNUM é um número inteiro de 24 bits gerado randomicamente pelo terminal. O terminal remoto quando recebe a mensagem MasterSlaveDetermination, verifica seu TT com o que veio na mensagem. O terminal que tiver o TT maior fica sendo o master e o outro o slave. Porém, se os TT forem iguais, são então comparados os dois SDNUM (recebido e local) e quem tiver o SDNUM maior será o master. Caso eles sejam iguais também, o terminal onde está sendo feita a comparação fica sendo o master. O terminal que realizou estas comparações preenche a mensagem MasterSlaveDeterminationAck com a informação master ou slave invertida, ou seja, ele manda a mensagem dizendo qual será o estado do receptor, se master ou slave. Por sua vez o receptor da mensagem MasterSlaveDeterminationAck envia para o originador uma outra mensagem MasterSlaveDeterminationAck com o estado do terminal que irá receber esta mensagem, assim como ilustra a figura 10. Figura 10 - Troca de mensagens Master Slave Determination 36 / 123

38 Logical Channel Signalling A transmissão de áudio, vídeo e dados é feita através de canais lógicos abertos depois de estabelecida as capacidades dos terminais. Os canais lógicos criados com o protocolo H245 para conferências H323 são unidirecionais, por isso cada elemento abre um canal lógico para transmitir informações ao outro. Além disso, cada canal lógico é aberto com uma descrição do tipo de dado a ser transportado naquele canal, por isso para um elemento da rede enviar áudio e vídeo ele deve abrir um canal lógico para o envio do áudio e outro para o envio do vídeo como mostra a figura 11. Figura 11 Canais lógicos entre dois terminais Para abrir um canal lógico, o terminal local envia uma mensagem OpenLogicalChannel para o terminal remoto com um conjunto de parâmetros deste canal lógico que será aberto. Este conjunto de parâmetros chamado de FP possui as seguintes informações: O número do canal a ser aberto; O número da porta UDP utilizada pelo RTP; O número da porta UDP utilizada pelo RTCP; Os tipos de dados e os codecs utilizados. Esta mensagem será recebida pelo terminal remoto e se ele aceitar a abertura do canal lógico, ele retornará a mensagem OpenLogicalChannelAck. Assim que o terminal local receber a mensagem OpenLogicalChannelAck o canal lógico estará aberto. Caso o terminal remoto não aceite a abertura do canal lógico, ele retornará a mensagem OpenLogicaChannelReject. 37 / 123

39 Para fechar o canal lógico aberto por ele, o terminal local enviará a mensagem CloseLogicalChannel e o terminal remoto retornará a confirmação CloseLogicalChannelAck. A figura 12 ilustra a troca de mensagens entre dois terminais para a abertura e o fechamento de canais lógicos. Figura 12 - Abertura e fechamento de canal lógico pelo mesmo terminal Porém, o terminal remoto, que não abriu o canal, pode pedir o fechamento deste canal lógico para o terminal local, como ilustra a figura 13. O terminal remoto envia uma mensagem RequestChannelClose pedindo para que o terminal local feche o canal lógico. O terminal local fecha o canal lógico enviando a mensagem RequestChannelCloseAck, porém se ele não aceitar o fechamento do canal lógico ele envia a mensagem RequestChannelCloseReject. 38 / 123

40 Figura 13 - Abertura de canal lógico por um terminal e fechamento por outro Mode Request Através da mensagem RequestMode o terminal remoto pode pedir tipos específicos de transmissão para o terminal local transmissor. Esta mensagem carrega uma lista de tipos de áudio, tipos de vídeo, tipos de dados e tipo de encriptação em ordem de preferência que o terminal remoto quer receber. Por exemplo, para áudio pode ser especificada a taxa de transmissão que ele deseja receber, para vídeo pode ser especificada a resolução do vídeo que ele deseja receber, para dados pode ser especificado o uso do protocolo T120 e a taxa de transmissão, além de poder também ser especificada a utilização de encriptação. Esta possibilidade só é possível se o terminal local já tiver enviado a mensagem com suas capacidades (TerminalCapabilitySet) ao terminal remoto, pois este utiliza as capacidades do terminal local para escolher as suas preferências que farão parte da mensagem RequestMode. Esta mensagem carrega um parâmetro chamado MODE-EL (Mode Element) que contém os tipos de áudio, vídeo, dados e encriptação em ordem de preferência do receptor. 39 / 123

41 Se o terminal local aceitar transmitir em um dos tipos especificados pelo terminal remoto, ele envia a mensagem RequestModeAck para o receptor como mostra a figura 14. Figura 14 Alteração no canal lógico a pedido do terminal remoto Round Trip Delay Determination A mensagem RoundTripDelay é utilizada para medir o atraso no canal de controle de acordo com o tempo entre o envio da mensagem e o recebimento da resposta. O terminal local envia a mensagem RoundTripDelay para o terminal remoto e começa a contar o tempo. Assim que o terminal remoto recebe esta mensagem, ele responde automaticamente com a mensagem RoundTripDelayAck como ilustra a figura 15. Logo que o terminal local recebe esta mensagem ele para de contar o tempo. Figura 15 - Medição do atraso no canal de controle 40 / 123

42 Comandos Os comandos são diferentes das requisições (mensagens request), pois exigem uma ação e não uma resposta do terminal remoto. Estes comandos são definidos para permitir principalmente que o terminal remoto tenha também o controle do tipo de transmissão. Os comandos utilizados pelo H323 são: End Session: é usado para encerrar o envio de mensagens H245 e informar que a chamada esta sendo encerrada também. Miscellaneous Comand: é usado para pedir alteração na atualização de quadros do vídeo, para congelar vídeo, para acelerar vídeo, para pedir correção no caso de perca de pacotes de vídeo, para distribuir chaves de encriptação, etc Indicações As indicações são mensagens que apenas informam o terminal receptor, não exigindo nenhuma resposta como as requisições ou ação como os comandos. A indicação utilizada pelo padrão H323 é: FunctionNotSupported: esta indicação é enviada quando uma resposta, uma requisição ou um comando não foi entendido ou não é suportado. Esta indicação também pode ser chamada de FunctionNotUnderstood H235 Sistemas H.323 operam sob redes baseada em pacotes, que não provêm qualidade de serviço garantido. Pelas mesmas razões técnicas que a rede não fornece QoS, a rede não fornece um serviço de segurança. Segurança na comunicação de tempo real sob uma rede não-segura geralmente envolve duas áreas de maior preocupação: autenticação e privacidade. 41 / 123

43 A recomendação H.235 da ITU-T descreve a infraestrutura de segurança e especifica técnicas de privacidade a serem empregadas por terminais multimídia da série H. Incluem autenticação e privacidade de todo fluxo de mídia de tempo real que é transportada em uma conferência. Essa recomendação fornece os protocolos e algoritmos necessários entre entidades H.323. O esquema proposto é aplicado tanto a conferências simples ponto-a-ponto como conferências multiponto para terminais multimídias baseados no protocolo de controle H.245. O protocolo H.235 utiliza as facilidades gerais suportadas pelo protocolo de controle H.245 e, conseqüentemente, qualquer padrão que opere em conjunto com esse protocolo pode usar esta estrutura de segurança. O H.235 inclui a habilidade de negociar serviços e funcionalidades, e selecionar técnicas de criptografia e potencialidades utilizadas. A maneira específica na qual é usada relata ao sistema as potencialidades, os requisitos da aplicação e a política de segurança específica. Suporta variados algoritmos de criptografia, com várias opções apropriadas para diferentes propósitos. Essa recomendação suporta sinalização de algoritmos bem-conhecidos além de sinalização a algoritmos de criptografias não-padronizados. Não há nenhum algoritmo especificamente exigido, entretanto, é fortemente sugerido suporte a algoritmos aplicáveis, tanto quanto possível, a fim de conseguir interoperabilidade. A versão 2 do H.235, caracteriza diversas melhorias tais como: criptografia elliptic curve, perfis de segurança (simples baseada em senha e assinatura digital sofisticada), novas contramedidas de segurança (anti-spamming), suporte a algoritmos de criptografia avançados (AES - Advanced Encryption Algorithm), suporte a serviço backend, identificadores de objetos definidos e mudanças incorporadas pelo guia de implementação do H.323. O funcionamento do protocolo H235 é o seguinte: O canal de sinalização de chamada pode ser seguro, usando TLS ou IPSEC sobre uma porta segura bem-conhecida (H.225.0); Usuários podem ser autenticados durante o início da conexão de chamada, através da troca de certificados no canal H.245; 42 / 123

44 A potenciabilidade de encriptação de um canal de mídia é determinada pela extensão de mecanismo existentes da negociação da potenciabilidade; A distribuição inicial da chave é realizada via mensagens H.245: OpenLogicalChannel ou OpenLogicalChannelAck; Re-chaveamento pode ser realizado pelos comandos H.245: EncryptionUpdateRequest e EncryptionUpdate; A distribuição da chave é protegida operando um canal H.245 como um canal privado ou especificamente protegendo a chave usando os certificados trocados selecionados. Scope of H.235 AV applications Terminal control and management Data applications G.XXX H.26X T.124 Encryption H Terminal to gatekeeper signalling (RAS) H Call signalling H.245 T.125 RTP Authentication RTCP Transport security Unreliable transport Reliable transport T.123 Network security Network layer Link layer Physical layer Figura 16 - Visão geral do protocolo H235 T / 123

45 A figura 16 é um escopo do protocolo H Autenticação O processo de autenticação verifica que os correspondentes são, de fato, quem dizem que são. A autenticação pode ser realizada juntamente com certificados baseado na troca de chave pública. Autenticação também pode ser realizada por uma troca que utiliza um segredo compartilhado entre as entidades envolvidas. Esta pode ser uma senha estática ou alguma outra parte de informação a priori. A recomendação H.235 descreve o protocolo para troca de certificados, mas não especifica os critérios pelos quais são mutuamente verificados e aceitados. A intenção atrás da troca do certificado é autenticar o usuário, não simplesmente físico. Usando certificados digitais, um protocolo de autenticação prova que os correspondentes possuem as chaves privadas que correspondem às chaves públicas contidas nos certificados. Esta autenticação protege contra ataques, mas não prova quem os correspondentes são. Fazer isto requer normalmente que haja alguma política a respeito dos outros índices dos certificados. Para certificados de autorização, por exemplo, o certificado normalmente conteria a identificação do serviço-fornecedor junto com algum formulário de identificação da conta do usuário prescrita pelo fornecedor de serviço. A estrutura de autenticação nesta recomendação não prescreve os índices dos certificados (isto é, não especifica uma política) além daqueles requeridos pelo protocolo de autenticação. Entretanto, uma aplicação que usa esta estrutura pode impor exigências de uma política de nível alto, tais como apresentar o certificado ao usuário para aprovação. Esta política de um nível mais elevado pode ser automatizada dentro da aplicação ou exigir a interação humana. Para autenticação que não utiliza certificados digitais, esta recomendação fornece sinalização para completar vários cenários de desafio/resposta. Este método de autenticação requer a coordenação prévia pelas entidades comunicando-se de modo que um segredo compartilhado possa ser obtido. Um exemplo deste método seria um cliente de um serviço baseado em subscrição. 44 / 123

46 Como uma terceira opção, a autenticação pode ser completada dentro do contexto de um protocolo de segurança, tais como TLS ou IPSEC. Ambas autenticações bidirecional e unidirecional podem ser suportadas por entidades pares. Esta autenticação pode ocorrer em alguns ou em todos os canais de comunicação Privacidade A recomendação H.235 descreve a privacidade de fluxos de mídia para transportes baseados em pacotes. Estes canais podem ser unidirecional respeitando as características do canal lógico H.245. Um primeiro passo para alcançar a privacidade deve ser a provisão de um canal de controle privado em que se estabeleça a chave criptográfica e/ou se ajuste os canais lógicos que carregarão o fluxo de mídia criptografado. Para esta finalidade, ao se operar em uma conferência segura, todos os participantes podem utilizar um canal H.245 criptografado. Desta maneira, a seleção dos algoritmos de criptografia e das chaves criptográficas passadas no comando de H.245 OpenLogicalChannel são protegidas. O canal seguro H.245 pode ser operado com as características diferentes daquelas do canal privado como fornecer um nível de privacidade mutuamente aceitável. Isto permite aos mecanismos de segurança proteger fluxos de mídia e todos os canais de controle para operar de maneira completamente independente, fornecendo níveis completamente diferentes da força e da complexidade. Se for exigido que a canal H.245 seja operado de uma maneira não criptografada, as chaves específicas de criptografia podem ser criptografadas separadamente da maneira sinalizada e concordada pelos participantes. Um canal lógico do tipo H235Control pode ser utilizado para fornecer o material para proteger as chaves de criptografia. Este canal lógico pode ser operado em toda a modalidade apropriadamente negociada. 45 / 123

47 A privacidade dos dados carregados em canais lógicos estará no formulário especificado pelo OpenLogicalChannel. A informação Transport-specific do cabeçalho não deve estar criptografada. A privacidade dos dados deve ser baseada na criptografia fim-a-fim Segurança Há pelo menos duas razões para motivar um canal seguro para estabelecimento da chamada (por exemplo, H.323 usando Q.931). O primeiro é para autenticação simples, antes de aceitar a chamada. A segunda razão deve permitir a autorização da chamada. Se esta funcionalidade for desejada no terminal da série H, uma modalidade segura de comunicação deve ser usada (como TLS/IPSEC para H.323) antes da troca de mensagens da conexão da chamada. Alternativamente, a autorização pode ser fornecida baseada em autenticação de um serviço específico. O canal do controle da chamada (H.245) deve também ser seguro de alguma maneira para fornecer privacidade. O canal H.245 deverá ser seguro usando todo o mecanismo de privacidade negociado (esta inclui a opção de "nenhum"). As mensagens H.245 são utilizadas para sinalizar os algoritmos e as chaves de criptografia usados nos canais privados compartilhados. A habilidade de fazer isto, em um canal lógico, permite diferentes canais de mídias serem criptografados por diferentes mecanismos. Por exemplo, em conferências multiponto centralizadas, diferentes chaves podem ser usadas para o fluxo em cada elemento da rede. Isto pode permitir que os fluxos de mídia sejam privados para cada elemento da rede na conferência. A fim de utilizar as mensagens H.245 de maneira segura, a canal H.245 inteiro (canal lógica 0) deve ser aberto de uma maneira segura negociada. O mecanismo pelo qual H.245 se torna seguro depende dos terminais da série H envolvidos. A única exigência em todos os sistemas que utilizam esta estrutura de segurança é que cada um deverá ter alguma maneira de negociar e/ou sinalizar que o canal H.245 deve ser operado de uma maneira particular e segura antes que seja iniciada realmente. Por exemplo, H.323 utilizará a conexão H que sinaliza mensagens para realizar isto. 46 / 123

48 O canal de conexão da chamada (H para a série H.323) e o canal do controle da chamada (H.245) deverão operar na modalidade negociada segura ou não-segura que começa com a primeira troca. Para o canal de conexão da chamada, isto é feito a priori [para H.323, um TLS seguro TSAP (porta 1300) será utilizado para as mensagens Q.931]. Para o canal de controle da chamada, a modalidade da segurança é determinada pela informação passada no protocolo inicial da configuração da conexão em uso pelo terminal das séries H. Nos casos em que não há nenhuma potencialidade de segurança, o terminal chamado pode recusar a conexão. O erro retornado não deve convergir a nenhuma informação sobre qualquer defeito de segurança; o terminal de chamada terá que determinar o problema por algum outro meio. Nos casos onde o terminal de chamada recebe uma mensagem CONNECT ACKNOWLEDGE sem potencialidade de segurança suficiente, ele deve terminar a chamada. Se a chamada e os terminais chamados tiverem potencialidades compatíveis de segurança, deverá ser assumido, por ambos, que o canal H.245 deverá operar na modalidade de segurança negociada. A falha no canal H.245 na modalidade de segurança determinada aqui deve ser considerada um erro do protocolo e a conexão terminada. No geral, os aspectos da privacidade dos canais de mídias são controlados da mesma maneira que qualquer outro parâmetro codificado; cada terminal indica suas potencialidades, a origem dos dados seleciona um formato a ser usado, e o receptor reconhece ou nega a modalidade. Todos os aspectos do mecanismo independentes do transporte, tais como a seleção do algoritmo, são indicados em elementos genéricos do canal lógico. Os aspectos específicos do transporte, tais como sincronização do algoritmo de chave/encriptação, são passados em estruturas transport-specfic. Supondo que os procedimentos do estabelecimento da conexão indicam uma modalidade de operação segura, o handshake e a autenticação negociados deverão ocorrer para o canal lógico H.245 antes que quaisquer outras mensagens H.245 sejam trocadas. Se negociado, toda troca de certificados deverá ocorrer usando qualquer mecanismo apropriado para o terminal das séries H. Após ter completado a segurança do canal H.245, os terminais usam o protocolo H.245 da mesma maneira que usariam em uma modalidade não-segura. 47 / 123

49 Alternativamente, o canal H.245 pode operar de maneira não-segura e as duas entidades abrem um canal lógico seguro com o qual executam a autenticação e/ou derivação do segredo compartilhado. Por exemplo, TLS ou IPSEC podem ser utilizados abrindo um canal lógico com o datatype que contem um valor para h235control. Este canal poderia então ser usado para derivar um segredo compartilhado que protegesse todas as chaves da sessão de mídia ou transportar o EncryptionSync. Seguindo os procedimentos da troca das potencialidades e a recomendação apropriada do sistema das séries H, os elementos da rede trocam suas potencialidades usando as mensagens H.245. As potencialidades podem agora conter as definições que indicam os parâmetros da segurança e criptografia. Por exemplo, um elemento da rede pode fornecer capacidade para emitir e receber vídeo H.261. Pode também sinalizar a habilidade de emitir e receber vídeo H.261 criptografado. Cada algoritmo de criptografia que é utilizado conjuntamente com um codec implica uma nova definição da potencialidade. Como com qualquer outra potencialidade, os elementos da rede podem fornecer codecs criptografados independentes e dependentes em sua troca. Isto permitirá que os elementos da rede escalem seus potenciais de segurança baseadas nas despesas gerais e nos recursos disponíveis. Depois que a troca da potencialidade foi completada, os elementos da rede podem abrir os canais lógicos seguros da mesma maneira que fariam de maneira não-segura. Os elementos da rede abrem os canais lógicos seguros da mesma maneira que abrem os canais lógicos não-seguros. Cada canal pode operar de maneira completamente independente de outros canais - nos detalhes pertencentes à segurança. A modalidade particular deverá ser definida no campo do datatype do OpenLogicalChannel. A chave inicial de criptografia será passada no OpenLogicalChannel ou em OpenLogicalChannelAck dependendo do relacionamento master/slave do originador do OpenLogicalChannel. O OpenLogicalChannelAck agirá como a confirmação da modalidade de criptografia. Se o OpenLogicalChannel for inaceitável ao receptor, o datatypenotsupported ou datatypenotavailable deverá ser retornado no campo cause do OpenLogicalChannelReject. 48 / 123

50 Durante a troca do protocolo que estabelece o canal lógico, a chave criptográfica será passada do master ao slave (não importando quem inicia o OpenLogicalChannel). Para os canais de mídia abertos por um elemento da rede (à exceção do master), o master deverá retornar a chave inicial de criptografia e o ponto inicial da sincronização no OpenLogicalChannelAck (no campo do encryptionsync). Para os canais de mídia abertos pelo master, o OpenLogicalChannel incluirá a chave inicial de criptografia e o ponto da sincronização no campo do encryptionsync Particularidades da Conferência Multiponto A autenticação deverá ocorrer entre um elemento da rede e a MCU da mesma maneira que em uma conferência ponto-a-ponto. A MCU deverá ajustar a política a respeito do nível de autenticação. A MCU é confiável; os elementos da rede existentes em uma conferência podem ser limitados pelo nível de autenticação empregado pela MCU. Os novos comandos de ConferenceRequest/ConferenceResponse permitem que os elementos da rede obtenham os certificados de outros participantes na conferência da MCU. Os elementos da rede em uma conferência multiponto podem pedir outros certificados do elemento da rede através do MCU, mas não podem executar a autenticação criptográfica direta com o canal H.245. O MCU deverá ganhar todas as trocas master/slave e fornecer a chave criptográfica aos participantes em uma conferência multiponto. A privacidade para fontes individuais dentro de uma sessão comum (multicast) pode ser conseguida com chaves individuais ou comuns. Estas duas modalidades podem arbitrariamente ser escolhidas pela MCU e não deverão ser controladas por nenhum elemento da rede particular a não ser nas modalidades permita pela política da MCU. Ou seja, uma chave comum pode ser usada através dos múltiplos canais lógicos abertos por diferentes fontes. Os fluxos de mídia deverão ser codificados usando o algoritmo e a chave como apresentados no canal H.245. A figura 17 mostra o fluxo geral de encriptação e a figura 18 mostra o fluxo geral de decriptação. Note que o cabeçalho de transporte está unido ao transporte SDU (Service Data Unit) depois que o SDU é criptografado. Os segmentos opacos indicam a privacidade. Como as chaves novas são recebidas pelo transmissor e usadas na criptografia, o cabeçalho do SDU deverá indicar de alguma maneira ao receptor que a chave nova está agora em 49 / 123

51 uso. Por exemplo, no H.323 o cabeçalho RTP (SDU) deverá mudar o tipo do payload para indicar ao interruptor sobre a chave nova. Codec Keys as passed in the H.245 channel Key #2 Key #1 Transport segmentation abcd abcd abcd abcd Encryption T SDU header Figura 17 - Encriptação 50 / 123

52 Codec Keys as received in the H.245 channel Key #2 Key #1 Transport de-segmentation abcd abcd abcd abcd Decryption T SDU header Figura 18 - Decriptação T120 Este protocolo é responsável pelo serviço de compartilhamento e transferência de arquivos, além do serviço de chat. Os produtos que implementam a tecnologia T.120 oferecem os seguintes benefícios para os usuários: T.120 assegura que muitos participantes podem enviar e receber dados em tempo real sem qualquer erro de transmissão. Os usuários podem esperar essa confiabilidade através de muitos tipos de conexões inclusive o TCP/IP. 51 / 123

53 Para conferência multiponto, o padrão T.120 suporta uma variedade de topologias comuns inclusive conexões cascaded, star e daisy-chain. Desenvolvedores podem criar aplicações com o padrão T.120 somente, ou com algum outro padrão da ITU como o padrão H.323 usado para áudio e vídeo conferência. Uma das mais importantes funções da infraestrutura do T.120 é a interoperabilidade dos produtos e serviços que suportam este padrão. Esta interoperabilidade é medida em dois níveis: rede e aplicação. Os padrões T.122, T.123, T.124 e T.125 compõem o nível de rede do padrão T.120. Os produtos e serviços que seguem estes padrões possuem a infraestrutura necessária para executar as seguintes funções: Estabelecer e manter conferências sem qualquer dependência de plataforma. Gerenciar múltiplos participantes e programas. Enviar e receber dados com eficiência e segurança numa grande variedade de conexões que suportam o padrão T.120. Os padrões T.126 e T.127 compõem o nível de aplicação do padrão T.120. Esses padrões asseguram que as aplicações de bate-papo e transferência de arquivos desenvolvidos no padrão T.120 podem interoperar através de plataformas e redes distintas e também em conferências com múltiplos usuários. A figura 19 mostra a arquitetura T.120. Esta arquitetura segue o modelo OSI, que especifica uma série de camadas, incluindo protocolos de níveis de rede inferiores para conexão, transmissão de dados e interação com os protocolos de níveis de rede superiores. 52 / 123

54 Figura 19 - Funcionamento do protocolo T H450 A série de protocolos H450.x permite que elementos de redes H323 adquiram capacidade de realizar tarefas próprias de telefonia, em conferências H323. Para fazer a sinalização de um protocolo da série H450.x, são utilizadas as mensagens de Setup, Call Proceding, Alerting, Connect, Release Complete, Facility e Progress do protocolo Q931. Utilizando a série H450.x, as conferências H323 podem adquirir diversas capacidades como: transferência de chamadas, chamada em espera, intrusão de chamada, etc. Uma das mais úteis capacidades de telefonia que os elementos da rede H323 podem adquirir é a transferência de chamadas (H450.2). A transferência de chamadas consiste em um 53 / 123

55 usuário A que tem uma chamada estabelecida com o usuário B transformá-la em uma chamada de B para C, sendo que o usuário C pode ter ou não uma chamada estabelecida com o usuário B. O protocolo H450.2 especifica como esta transferência ocorre. Caso o usuário C não tenha uma chamada estabelecida com A ou B, o primeiro passo para a transferência da chamada consiste em o usuário A enviar uma mensagem para o B pedindo-o para iniciar uma chamada com o C. A chamada do usuário A com o B continua aberta normalmente e só será encerrada pelo B com uma resposta positiva do usuário C. Esta resposta positiva pode ser uma mensagem Alerting ou Connect do protocolo Q931 como mostra a figura 20. A B C T3 FACILITY(ctInitiate.Invoke) T4 SETUP(ctSetup.Invoke) CONNECT(ctSetup.ReturnResult) RELEASE COMPLETE (ctinitiate.returnresult) Figura 20 Trocas de mensagens na transferência de chamada sem o C estar conectado Caso o usuário C já tenha uma chamada estabelecida com o A, a primeira troca de mensagens será diferente. O usuário A envia uma mensagem para o C pedindo autorização para que possa ser feita a transferência da chamada. O usuário C autoriza e a transferência, a partir deste ponto, ocorre da mesma maneira que o caso em que o usuário C não está conectado. Uma outra diferença na troca de mensagens é que logo após o usuário C enviar a mensagem Connect para o B, ele encerra a chamada com o A enviando a mensagem Release Complete como mostra a figura / 123

56 T1 A FACILITY(ctIdentity.Invoke) B C T2 FACILITY(ctIdentity.ReturnResult) T3 FACILITY(ctInitiate.Invoke) T4 SETUP(ctSetup.Invoke) RELEASE COMPLETE (ctinitiate.returnresult) CONNECT(ctSetup.ReturnResult) RELEASE COMPLETE Figura 21 Trocas de mensagens na transferência de chamada com o C conectado ao A Audio Codec A voz humana é uma forma de onda mecânica com freqüências principais na faixa que vai de 300 a 3400 Hz. Para a reprodução com qualidade da voz humana em um terminal à distância, existe a necessidade de se codificar e decodificar a voz sobre um formato digital, cuja responsabilidade é do Audio Codec. O Audio Codec transforma as ondas analógicas da voz humana em ondas digitais que são transmitidas para outro terminal onde há um Audio Codec que as transforma mais uma vez em ondas analógicas que serão ouvidas por outra pessoa. O Audio Codec utilizado influi na qualidade do sistema de várias maneiras, pois ele inclui por si uma distorção na amostra de voz. Esta distorção pode ser comparada entre vários Audio Codecs utilizando a técnica MOS (Mean Opinion Score) de avaliação de qualidade acústica da voz como mostra a figura 22 e a tabela IV. Outro aspecto a ser observado é a largura de banda ocupada por um sinal de voz, pois em uma rede saturada isto pode ser crítico. 55 / 123

57 Figura 22 - Comparação de Audio Codecs Nota Significado Ruim: ininteligível, o usuário não entende a mensagem decodificada. Possui interrupções horríveis. Pobre: o sinal possui interrupções e o usuário tem que fazer um esforço considerável para entender alguns trechos. Moderado: a qualidade da voz é ruim, o usuário sente incomodado com a qualidade do som, porém não tem interrupções e ainda consegue entender a mensagem (requer esforço moderado). Bom: a voz é agradável de se ouvir, ou seja, percebe-se perda de qualidade do som mas não se incomoda com ela, pois é mínima (nenhum esforço apreciável é requerido). Excelente: o usuário não consegue diferenciar o trecho original do corrompido, ou seja, não se percebe perca de qualidade do sinal (nenhum esforço é requerido). Tabela IV - Notas MOS de avaliação de qualidade acústica da voz Vídeo Codec Assim como o áudio, o vídeo também tem que ser codificado e para isso é utilizado o Video Codec. A ITU criou os Video Codecs H261 e H263 para serem utilizados em videoconferência. Os dois codecs são para vídeos coloridos e a diferença entre eles esta na performance que compreende o formato do vídeo suportado pelo codec, a resolução, a taxa de quadros exibidos por segundo e a largura de banda ocupada pelo sinal de vídeo. A taxa de 56 / 123

58 transmissão de sinal de vídeo utilizando o H261 é maior ou igual a 64kbps e, já utilizando o H263, é menor que 64 kbps. Os formatos de vídeo são todos baseados no CIF (Common Interchange Format) que tem resolução 352x288 pixels. O tamanho da tela do SQCIF é ¼ da tela do QCIF que por sua vez é ¼ da do CIF. Já a tela do 16CIF é 4 vezes maior que a tela do 4CIF que por sua vez é 4 vezes maior que a do CIF como mostra a tabela V. Formato do Vídeo Resolução Taxa Max de Quadros /s H261 H263 SQCIF 128x96 30 Opcional Obrigatório QCIF 176x Obrigatório Obrigatório CIF 352x Opcional Opcional 4CIF 704x Impossível Opcional 16CIF 1408x Impossível Opcional Tabela V - Comparação entre H261 e H SIP O SIP (Session Initiation Protocol), criado pela IETF (Internet Engineering Task Force), é um protocolo cliente/servidor usado para iniciar uma sessão de comunicação entre usuários. Ele proporciona para o usuário serviços de estabelecimento de chamada, controle sobre os participantes e encerramento de chamada. O SIP é parecido com dois outros protocolos da internet: o HTTP (Hypertext Transfer Protocol) e o SMTP (Simple Mail Transfer Protocol), pois as requisições são geradas por uma entidade cliente e enviada a outra entidade servidor. O servidor processa a mensagem e envia a resposta ao cliente. A requisição e a resposta são chamadas de transação. A entidade cliente possui um elemento cliente e um elemento servidor, no qual o elemento cliente inicia uma 57 / 123

59 chamada e o elemento servidor responde à chamada. Isto permite que possam ser realizadas chamadas ponto a ponto entre duas entidades clientes usando um protocolo cliente-servidor. De acordo com a figura 23, na rede podem existir três tipos de servidores. Servidores Proxy Stateless que recebem as requisições do cliente e as encaminha a outro servidor até chegar ao usuário, porém não guardam as informações sobre as chamadas que passam por eles. Servidores Proxy Statefull que recebem as requisições do cliente e as encaminha a outro servidor até chegar ao usuário, guardando as informações sobre as chamadas que passam por eles. E os Servidores Redirect, que também recebem as requisições do cliente e determina qual o próximo Servidor (next-hop server). Figura 23 - Elementos que compõem uma rede SIP Segundo a RFC 3261/2002 todos os elementos SIP implementam obrigatoriamente UDP ou TCP como protocolo de transporte das mensagens SIP. Outros protocolos de transportes são opcionais e podem também ser utilizados. Já o áudio e o vídeo são transportados utilizando o protocolo RTP/RTCP. 58 / 123

60 A RFC 3261/2002 que especifica um padrão para o protocolo SIP, não faz nenhuma referência aos codecs de áudio e vídeo suportados Mensagens SIP Uma mensagem SIP é sempre uma requisição de um cliente para um servidor ou uma resposta de um servidor para um cliente. Os dois tipos de mensagens têm o mesmo formato, tendo como diferença apenas o primeiro campo das mensagens como mostra a figura 24. Figura 24 - Formato das mensagens de Requisição e de Resposta Mensagens de Requisição (Request) Na mensagem de Requisição o campo Request-line carrega a classe desta mensagem de requisição. De acordo com a RFC 3261/2002, as classes das mensagens de requisição são as seguintes: Register: é a mensagem enviada por um cliente a um servidor pedindo seu registro. Se o servidor aceitar esta requisição, ele criará um domínio para o cliente. Este domínio é o endereço do cliente para que outros possam se conectar a ele. Este domínio é como um endereço de , é único para cada cliente e serve para identificá-lo na rede. Options: é a mensagem que permite um cliente estabelecer as capacidades com outro cliente ou com um servidor. Através desta mensagem é possível obter informações sobre os tipos de mídia e os codecs suportados, antes de estabelecer uma chamada. 59 / 123

61 Invite: é a mensagem enviada pelo cliente ao servidor ou a outro cliente (se for conexão ponto a ponto), para o estabelecimento de uma chamada. ACK: é a mensagem enviada pelo cliente originador da conexão para informar que a conexão já está estabelecida. Esta mensagem só é enviada após o originador receber a resposta do receptor aceitando a conexão. Cancel: é a mensagem enviada pelo cliente originador, cancelando a chamada. Bye: é a mensagem enviada por qualquer uma das partes encerrando a chamada. A figura 25 ilustra a troca de mensagens SIP entre dois clientes conectados a dois servidores proxy diferentes. Figura 25 - Troca de mensagens SIP Mensagens de Resposta (Response) 60 / 123

62 Na mensagem de resposta o campo Status-line identifica o número da mensagem de resposta e uma descrição desta mensagem. Este número contém três algarismos e o primeiro deles identifica a classe da mensagem. De acordo com a RFC 3261/2002, as classes de resposta e seus respectivos números são os apresentados na tabela VI. Nº da Classe Classe Descrição 1xx Provisória A requisição foi recebida e está em processamento. 2xx Sucesso A ação foi recebida, entendida e aceita com sucesso. 3xx Redirecionamento Outra ação terá que ser feita para completar a requisição. 4xx Client Error A requisição tem erro de sintaxe ou o servidor não pode realizar a ação requisitada. 5xx Server Error O servidor não conseguiu realizar uma ação requisitada aparentemente válida. 6xx Global Failure A requisição não pode ser atendida por nenhum servidor. Tabela VI Classes das Mensagens de Resposta Mensagens Provisórias Estas mensagens informam ao cliente que o servidor está realizando tarefas para obter a resposta e enviá-la ao cliente. Porém, esta resposta demorará mais de 200 ms para ser obtida pelo servidor. O recebimento destas mensagens provisórias não precisa ser confirmado. De acordo com a RFC 3261/2002, as mensagens provisórias são os dispostos na tabela VII. Nº da mensagem Mensagem Descrição 100 Trying Esta mensagem indica que a requisição foi recebida pelo servidor sequinte e que ele está realizando as tarefas requisitadas. 180 Ringing Indica que o usuário destinatário de uma mensagem INVITE está sendo alertado do pedido de estabelecimento de chamada. 61 / 123

63 181 Call Forwarded Indica que a chamada está sendo transferida para outros destinatários. 182 Queued O destinatário está temporariamente inacessível, mas o servidor ao qual ele está conectado preferiu colocar o pedido de estabelecimento de chamada (INVITE) na fila de espera em vez de rejeita-lo. 183 Session Progress É utilizada para informar sobre o progresso de uma chamada. Tabela VII Mensagens Provisórias Mensagens de Sucesso Estas mensagens indicam que a requisição foi aceita com sucesso. Só existe uma mensagem deste tipo que é a 200 OK Mensagens de Redirecionamento Estas mensagens são utilizadas para indicar a nova localização do destinatário. De acordo com a RFC 3261/2002, as mensagens de redirecionamento são as constantes na tabela VIII. Nº da mensagem Mensagem Descrição 300 Multiple Choices Esta é a resposta de uma requisição na qual o endereço especificado poderia ser de vários destinatários. 301 Moved Permanently Esta é a resposta de uma requisição na qual o destinatário não pode mais ser encontrado no endereço especificado. Esta mensagem já traz o endereço atual do destinatário. 302 Moved Temporarily Esta é a resposta de uma requisição na qual o destinatário temporariamente não pode ser encontrado no endereço especificado. Esta mensagem já traz o endereço atual do destinatário. 305 Use Proxy Apenas um Servidor Proxy pode enviar certa requisição, 62 / 123

64 porém ela foi enviada por outro elemento da rede. 380 Alternative Service A requisição não obteve sucesso, porém é possível a utilização de serviços alternativos que são descritos na mensagem. Tabela VIII Mensagens de Redirecionamento Mensagens Client Error Estas mensagens são respostas de servidores a clientes, indicando que houve um erro na requisição e que o cliente precisará fazer alterações nesta requisição para que a envie novamente ao servidor. Esta mensagem não implica que a mesma requisição que não foi aceita por um servidor, não poderá ser aceita por outro. De acordo com a RFC 3261/2002, as mensagens Client Error são as especificadas na tabela IX. Nº da mensagem Mensagem Descrição 400 Bad Request A requisição não pode ser entendida por erro de sintaxe, indicando qual é o erro. 401 Unauthorized A requisição não pode ser aceita por falta de autenticação (similar à mensagem 407). 402 Payment Required Reservada para uso futuro. 403 Forbidden O servidor entendeu a requisição, mas não está aceitandoa. 404 Not Found O servidor tem a informação que o destinatário da requisição não existe. 405 Method Not Allowed A requisição foi entendida, porém não é permitida para o destinatário especificado. 406 Not Acceptable A requisição não foi aceita. 407 Proxy Authentication Required Indica que o cliente precisa autenticar-se no Servidor Proxy (similar à mensagem 401). 408 Request Timeout O servidor não conseguiu obter resposta à requisição a 63 / 123

65 tempo. 410 Gone O objeto da requisição não está disponível no servidor. 413 Request Too Large O servidor não conseguiu processar a requisição, pois esta era muito grande. 414 URI Too Long O sevidor não conseguiu processar a requisição, pois o endereço do destinatário está muito grande. 415 Unsupported Media Type 416 Unsupported URI Scheme O servidor está recusando a requisição, pois ela está em um formato que não é suportado pelo servidor. O servidor não pode processar a requisição, pois o endereço do destinatário está no formato errado. 420 Bad Extension O servidor não entende o protocolo especificado na requisição. 421 Extension Required O servidor necessita de uma extensão específica para processar a requisição. 423 Interval To Brief O servidor rejeita a requisição, pois o tempo para expirar é muito pequeno. 480 Temporarily Unavailable O servidor conseguiu contactar o destinatário requisição, porém ele não quer receber a requisição. da 481 Call Not Exist O servidor recebeu uma requisição de uma chamada que não existe. 482 Loop Detected O servidor detectou um loop, ou seja, a requisição nunca chegará ao destinatário e ficará rodando pela rede. 483 Too Many Hops Muitos servidores no caminho da requisição até ela chegar ao seu destino. 484 Address Incomplete O endereço do destinatário da requisição está incompleto. 485 Ambiguous O endereço do destinatário da requisição está ambíguo. 486 Busy Here O destinatário foi contactado com sucesso, porém ele não pode estabelecer outra chamada. 487 Request Terminated A requisição foi extinta por uma mensagem BYE ou CANCEL. 488 Not Acceptable Here A requisição não foi aceita pelo servidor, mas poderá ser 64 / 123

66 aceita por outro. 491 Request Pending A requisição foi recebida pelo servidor, mas ele tem outra requisição pendente. 493 Undecipherable A requisição foi recebida pelo servidor, mas ele não conseguiu decifrá-la. Tabela IX Mensagens Client Error Mensagens Server Error Ocorreu algum problema com o servidor e ele não conseguiu atender a uma requisição válida. De acordo com a RFC 3261/2002, as mensagens Server Error são as constantes na tabelax. Nº da mensagem Mensagem Descrição 500 Server Internal Error O servidor encontrou uma condição inesperada que o impediu de atender a requisição. 501 Not Implemented O servidor é capaz de realizar a tarefa requisitada. 502 Bad Gateway 503 Service Unavailable 504 Server Timeout O servidor, atuando como gateway, recebeu uma resposta inválida de outro servidor.. O servidor não pode atender a requisição, pois não está acessível. O servidor não recebeu uma resposta de outro servidor a tempo. 505 Version Not Supported A versão do protocolo SIP não é suportada pelo servidor. 513 Message Too Large A requisição não pode ser atendida, pois a mensagem excedeu seu tamanho máximo. Tabela X Mensagens Server Error 65 / 123

67 Mensagens Global Failure Estas mensagens indicam que a requisição não pode ser atendida por nenhum servidor da rede. De acordo com a RFC 3261/2002, as mensagens Global Failure são as descritas na tabelaxi. Nº da mensagem Mensagem Descrição 600 Busy Everywhere O destinatário da requisição foi contatado com sucesso, mas ele não quer receber chamada neste momento. 603 Decline O destinatário da requisição foi contatado com sucesso, mas ele não quer participar da chamada. 604 Not Exist Anywhere O servidor tem a informação de que o endereço do destinatário da requisição não existe em nenhum ponto da rede. 606 Not Acceptable O destinatário da requisição foi contatado com sucesso, mas alguns aspectos da chamada, como largura de banda, não podem ser aceitos. Tabela XI Mensagens Global Failure Autenticação A RFC 3261/2002 especifica que o protocolo SIP provê um sistema de autenticação. Toda vez que um Servidor Proxy recebe uma requisição, ele pede ao originador da mensagem que prove sua identidade. Assim que o originador se identificou, o servidor verifica se ele está autorizado para fazer a requisição. A identificação do originador da mensagem é encontrada no cabeçalho da requisição. O mecanismo de autenticação do SIP apenas provê autenticação da mensagem e proteção a repetição, não oferecendo garantia da integridade e da confidencialidade da mensagem. Outros mecanismos precisam ser implementados paralelamente ao SIP para proteger as mensagens de ataques que possam modificá-las. 66 / 123

68 5.3 MGCP O Media Gateway Control Protocol (MGCP), desenvolvido pela Nortel Networks, é um dos poucos padrões de sinal e controle a competir com o antigo padrão H.323 de conversão de sinais de áudio transmitidos por circuitos telefônicos (PSTN) em pacotes de dados para transmissão pela Internet ou outras redes. A razão pela qual novos padrões estão sendo desenvolvidos explica-se pela crescente popularidade da Voz por IP (Voice over IP - VoIP ). Os telefones regulares são relativamente baratos porque não precisam ser complexos; eles são fixados por uma conexão específica a uma central. Os telefones e dispositivos por IP, por outro lado, não são fixados por uma conexão específica a uma central; portanto, devem possuir processadores que os possibilitem funcionar e ser inteligentes sozinhos, independentes de uma central. Isso torna o terminal (telefone ou dispositivo) mais complexo e, por isso, mais caro. O MGCP tem a função de simplificar os padrões para essa nova tecnologia, eliminando a necessidade de dispositivos complexos de telefonia por IP e reduzindo o custo desses terminais. O MGCP foi desenvolvido para atender os requisitos de redes de telefonia IP que são implementados utilizando Gateways decompostos. As soluções de VoIP baseadas em MGCP separam as chamadas em controle de chamadas (sinalizações), inteligência e tratamento de media. O MGCP é um protocolo utilizado por controladores de chamadas externas chamados MGC (Media Gateway Controllers) e controlam o que chamamos de MG (Media Gateways). O MGCP é implementado como um protocolo interno a um sistema distribuído, mas parece estar fora como um simples Gateway de VoIP. Este sistema é composto de um Call Agent, que pode ou não ser distribuído através de várias plataformas, e por uma série de Gateways. Em uma configuração típica, este sistema terá uma interface ligada em um ou mais switches de telefonia, e a outra interface ligada em um sistema que siga o padrão H / 123

69 5.3.1 O Modelo MGCP Os Gateways VoIP que implementam o MGCP provêm uma solução muito abrangente para redes IP em geral e pode coexistir com redes que implementam o padrão H.323 e até mesmo o SIP. No modelo MGCP, os Gateways se reservam principalmente na função de traduzir sinais de áudio, enquanto o Call Agent cuida da sinalização e das chamadas. Como conseqüência, o Call Agent implementa as camadas de sinalização do padrão H.323 e se apresenta como se fosse o Gatekeeper ou até mesmo um ou mais Terminais do sistema H Arquitetura e Entidades MGCP O MGCP é um protocolo Master/Slave com uma união muito forte entre o MG (Terminal) e o MGC (Servidor). Como o SIP e o H.323, o MGCP conta com uma variedade de outros protocolos existentes como o SDP (Session Description Protocol), que descreve os aspectos da media utilizada na chamada, e o protocolo RTP/RTCP (utilizado pelos MG), para tratar o transporte de pacotes de tempo real. Na arquitetura MGCP, O servidor MGC ou Call Agent é obrigatório e controla as chamadas e conferências e ainda suporta os serviços necessários. O terminal MG não tem conhecimento das chamadas e conferências e não mantêm qualquer status de chamada. É esperado dos MG que executem comandos enviados pelo MGC Call Agents. O MGCP assume que os Call Agents se sincronizarão através do envio de comandos coerentes para os MG que estão sobre seu controle. O MGCP não define qualquer mecanismo para sincronizar os Call Agents. As entidades principais do modelo MGCP são os terminais e as Conexões. O MGCP assume um modelo de conexão onde os terminais e as Conexões são utilizadas para estabelecer caminhos de voz entre os participantes. Os terminais podem ser de origem ou destino e podem ser também virtuais ou físicos. A criação de um terminal físico requer a instalação de algum hardware enquanto que um terminal virtual requer somente um software. 68 / 123

70 As conexões podem ser tanto ponto-a-ponto como multiponto. Uma conexão ponto-aponto associa dois Terminais. A partir do momento em que esta associação é estabelecida para os dois terminais, a transmissão de dados entre os dois participantes pode começar. Uma conexão multiponto é estabelecida pela conexão de um Terminal a uma sessão multiponto. As conexões podem também ser estabelecidas utilizando vários tipos de redes: transmissão de pacotes de áudio usando o protocolo RTP e UDP através de redes TCP/IP, transmissão de pacotes de áudio usando AAL2 ou outra camada de adaptação através de redes ATM e transmissão de pacotes através de conexões internas. Tanto para conexões ponto-a-ponto quanto para multiponto, os terminais podem ficar em Gateways separados ou até mesmo no mesmo. O Controle de primitivas para as operações MGCP são sinais enviados do MGC para o MG, e os eventos enviados do MG para o MGC. Os conceitos de sinais e eventos são utilizados para estabelecer e fechar chamadas inativas. As operações são executadas enviando sinais para os terminais e detectando eventos vindos dos terminais. Um MGC inicia transações para gerenciar e configurar terminais MG usando comandos MGCP. MG enviam respostas para as transações requisitadas dos MGC utilizando tanto um comando de notificação quanto um de reinicialização Protocolo MGCP O MGCP implementa a Media Gateway Control Interface como uma variedade de transações. As transações são compostas de um comando e uma resposta. Existem oito tipos de comandos: CreateConnection: O Call Agent pode utilizar este comando para criar uma conexão que termina em um Terminal dentro do Gateway. ModifyConnection: O Call Agent pode utilizar este comando para alterar os parâmetros associados a uma conexão já existente. 69 / 123

71 DeleteConnection: O Call Agent pode utilizar este comando para encerrar uma conexão já existente. Este comando também pode ser usado pelo Gateway para indicar que aquela conexão não pode mais ser sustentada. NotificationRequest: O Call Agent pode enviar um comando de NotificationRequest para um Gateway instruindo-o para verificar eventos específicos de importância para o Call Agent. Notify: O Gateway enviará este comando para informar ao Call Agent quando o evento enviado no comando NotificationRequest ocorrer. AuditEndpoint e AuditConnection: O Call Agent pode utilizar estes comandos para auditorar o status de um Terminal e todas as conexões relacionadas a ele. O gerenciamento da rede através das capacidades providas por estes comandos é algo muito desejado pelos administradores de rede. Tais capacidades são esperadas que sejam suportadas pelo uso do protocolo SNMP e as definições de uma MIB. RestartInProgress: O Gateway pode utilizar este comando para notificar o Call Agent que o Gateway, ou um grupo de Terminais gerenciados por aquele Gateway, está saindo de serviço ou voltando ao serviço. Estes comandos possibilitam que um controlador (normalmente o Call Agent) instrua um Gateway na criação de conexões que terminam em um terminal conectado no Gateway e seja informado sobre eventos ocorridos no terminal. As conexões são agrupadas em chamadas. Muitas conexões, que podem ou não pertencer a uma mesma chamada, podem terminar no mesmo terminal. Cada conexão é qualificada por um parâmetro chamado modo (modo de execução), a qual pode ser configurado para send only, receive only, send/receive, conference, data, inactive, loopback, continuity test, network loop back ou network continuity test. A forma de tratamento dos sinais de áudio recebidos nessas conexões é determinado por estes parâmetros: 70 / 123

72 Sinais de áudio recebidos nos pacotes de dados pelas conexões em modo receive only, conference ou send/receive são mixados e enviados para o terminal. Sinais de áudio originados de um Terminal são transmitidos por todas as conexões que estiverem com modo send only, conference ou send/receive. Sinais de áudio recebidos nos pacotes de dados pelas conexões em modo conference são replicados para todas as outras conexões com modo conference. Os modos loopback e continuity test são utilizados durante manutenções e operações de testes de continuidade. No modo loopback, é esperado do Gateway que ele retorne o sinal de origem do Terminal para o próprio Terminal. Este procedimento será usado, tipicamente, para testar a continuidade dos circuitos de acordo com as especificações ITU. No modo continuity test, o Gateway é informado que a outra ponta do circuito iniciou um procedimento de teste de continuidade. O Gateway colocará o circuito no modo requerido pelo transmissor para testes dual-tono de continuidade. No modo network loopback, os sinais de áudio recebidos da conexão serão enviados de volta para a conexão de origem. No modo network continuity test, o Gateway processará os pacotes recebidos da conexão de acordo com o modo requerido pelo transmissor para testes dual-tone de continuidade, e enviará o sinal processado de volta para a conexão de origem Relacionamento entre MGCP, SIP e H.323 O MGCP é um protoloco complementar tanto para o SIP quanto para o H.323. Foi desenvolvido especialmente para atuar como um protocolo interno entre os MGC e os MG para arquiteturas com Gateway decomposto. No modelo MGCP, um MGC trata o processamento das chamadas se conectado, através de uma interface, com a rede IP via comunicações utilizando um 71 / 123

73 aparelho de sinalização IP como um Gatekeeper do padrão H.323 ou um servidor SIP. Utilizando a analogia H.323, o MGC implementa as camadas de sinalização do padrão H.323 e se apresenta como um Gatekeeper H.323 ou até mesmo com um ou mais Terminais. Dentro do MGCP, os MG têm a tarefa de traduzir sinais de áudio, permitindo conversões entre os sinais de áudio transportados pelos circuitos telefônicos e pacotes de dados transportados pela internet ou outro pacote de rede qualquer. O H.323 e o SIP trabalham muito bem como protocolos P2P. Se a rede possuir terminais inteligentes, pode ser negociado chamadas com voz, vídeo e até serviços de multicasting diretamente entre os terminais. Estes protocolos trabalham melhor em LANs. O SIP já faz boa parte que o H.323 faz hoje em dia e algumas funções que ainda faltam a IETF já está providenciando. O MGCP também é muito útil para empresas que precisam simplesmente simplificar seus Gateways focando principalmente em hardware e software. Mesmo que a escolha por um protocolo seja o MGCP, há a necessidade da troca de mensagens de sinalização senão só será possível completar e finalizar chamadas numa mesma rede com muitas limitações. Por isso a necessidade dos protocolos H.323 ou SIP que são protocolos de sinalização. 72 / 123

74 6 Telefonia IP Soluções baseadas em IP têm sido propostas em substituição aos modelos de telefonia convencional, com inúmeras vantagens. O método básico para comunicação telefônica é estabelecer um circuito entre dois assinantes: isto se faz ainda hoje na maioria das ligações tradicionais. Apesar da telefonia ter evoluído para circuitos digitais e multiplexados, a presença do circuito é indispensável na comunicação. A telefonia pública hoje é conhecida como Public Switched Telephone Network (PSTN) ou Rede Telefônica Publica Comutada (RTPC). Na telefonia o usuário é conhecido sempre por assinante. Com a utilização de redes de pacotes para tráfego de voz elimina-se a necessidade da presença de um circuito. Dentro destes conceitos, a voz é empacotada e transmitida em redes de computadores juntamente com os dados. O protocolo IP é o utilizado para este processo. A rede que estiver habilitada com esse protocolo poderá trafegar também voz, por isso poderá ser um ponto fundamental na sua escolha. Para realizar uma chamada são necessários protocolos de controle e sinalização para executar algumas tarefas com localização do usuário, notificação de chamada, início de transmissão de voz, finalização de transmissão de voz e desconexão. Hoje em dia a arquitetura mais difundida no mercado para transmitir voz sobre Local Area Network (LAN) é o padrão H.323. Para a transmissão do fluxo de voz, utiliza-se o protocolo RTP. O RTP utiliza o serviço de transporte UDP para transmitir os pacotes. O RTP é necessário porque na Telefonia IP uma taxa de transmissão constante é fundamental, enquanto que a perda de pacotes pode ser desprezada. 73 / 123

75 6.1 Voz sobre IP Voz sobre IP ou VoIP é uma tecnologia que permite a digitalização e codificação de voz e o empacotamento de dados IP para a transmissão em uma rede que utilize TCP/IP. Devido ao volume de dados gerado por uma aplicação VoIP, esta tecnologia se encontra em funcionamento em redes corporativas privadas, mas se a rede base para transporte desta aplicação for a Internet, não é aconselhável que seja utilizada para fins profissionais, pois o TCP/IP não oferece padrões de Qualidade de Serviço (QoS) comprometendo desta forma a qualidade da voz. A qualidade da voz fica dependente do tráfego de dados existentes no momento da conversa. Uma grande diferença entre uma aplicação de dados e uma aplicação de voz é que uma aplicação de voz é sensível ao atraso. Em uma rede IP não é possível garantir um atraso constante o que pode tornar uma aplicação de voz em tempo real, como por exemplo, uma ligação telefônica, um serviço de baixa qualidade com a voz entrecortada e muitas vezes inteligível. Voz sobre IP é um conceito relativamente simples: transformar voz em mais uma aplicação IP dentro de uma rede de dados que utilize IP como protocolo de nível de rede. Aliás, esta simplicidade é que permite transmitir dados e voz dentro de uma mesma rede, completamente anárquica e dispersa, a custos relativamente baixos. A grande diferença entre as aplicações de dados, excluindo-se multimídia, e as de voz é a incapacidade de uma rede de oferecer atraso constante a uma aplicação de voz on-line, como é uma ligação telefônica, que causa retardos indesejáveis para os usuários. Na prática, esta limitação introduz voz entrecortada e muitas vezes ininteligível. A capacidade de uma rede em oferecer atrasos constantes pode ser adiquirida através de uma política de QoS. Independente da tecnologia adotada, o movimento de integração entre voz e dados na mesma infra-estrutura de rede, há alguns anos já é esperado. As vantagens são claras, pois os custos envolvidos na manutenção de equipes técnicas, infra-estruturas diferenciadas e ligações internacionais são reduzidos com a integração. O aumento do leque de novas aplicações, da disseminação de microcomputadores pessoais (para funcionamento como terminal multimídia), das capilaridades redes IP e da banda de transmissão disponível para o usuário, contribuíram em muito para VoIP tornar-se uma realidade. 74 / 123

76 Contudo, a diferença de preço entre o terminal telefônico convencional e um equipamento para uso de VoIP, ainda é um forte fator limitante para uso desta última solução em larga escala. Além disso, a alta disponibilidade das redes telefônicas convencionais aliadas à falta de qualidade de serviço e de confiabilidade da rede, originalmente herdada do IP, são aspectos de peso na comparação entre os ambientes legado e VoIP. Apesar e tais desvantagens, e devido aos enormes benefícios introduzidos pela integração entre telefonia e IP, a mudança de cenário de comunicação de voz e dados atual para uma realidade integrada em larga escala, onde os meios de transmissão deverão servir aos dois mundos de forma transparente ao usuário, é uma realidade almejada. Um engano sobre a telefonia IP é pensar que seu maior benefício é para chamadas de longa distância de baixo custo. Apesar das ligações de longa distância realmente estarem promovendo o uso da telefonia IP, as razões pelas quais as companhias são atraídas é a facilidade de criação de serviços e a consolidação de suas redes. A principal vantagem de Voz sobre IP (VoIP) sobre a rede telefônica pública comutada é a facilidade de adição de novos serviços e funcionalidades, assim como a significativa diminuição dos custos de implantação e manutenção por parte das companhias telefônicas. Por exemplo, pode-se criar uma videoconferência pela definição de como o fluxo de vídeo é codificado e decodificado. Fazer videoconferência sobre a RTPC pode ser um processo difícil e caro, porque a RTPC tem conceito rigoroso de circuitos, todos eles com largura de banda normalmente de 64 kbps. Para aplicações que exijam largura de banda maior, existe a necessidade de mais de um circuito para transmissão de um mesmo fluxo de vídeo. Da mesma forma, como a telefonia IP é baseada em software é mais fácil adicionar serviços como correio de voz e outros. A segunda vantagem para a telefonia IP é a consolidação das redes de dados, chamada de convergência das redes. Atualmente, companhias telefônicas mantêm duas redes, uma para voz e outra para dados. Como redes de voz são 4 ou 5 vezes mais caras que as redes de dados, o uso de VoIP elimina a rede de voz, gerando grande redução de custos. Pode-se ainda prever a integração de diversos serviços sobre o sistema telefônico, utilizando tecnologias agregadas como reconhecimento e síntese de voz. Por exemplo, é possível ouvir todos os s recebidos por um telefone convencional, utilizando a síntese de voz e 75 / 123

77 transmissão sobre IP para que estes s cheguem por telefone. Desta forma, serviços como fax, WWW e outros podem ser acessados através de telefones comuns. Será possível também a unificação das três redes hoje existentes para manutenção do sistema telefônico: a rede de transporte de voz, a rede de sinalização e a rede de gerência. Estas redes possuem hoje infra-estruturas independentes e muitas vezes sobre redes físicas diferentes. Com o uso da telefonia IP, unificam-se todas estas redes sobre a mesma infra-estrutura utilizando sempre o mesmo protocolo de rede: o protocolo IP. Um engano comum referente ao VoIP é a qualidade final de transmissão de voz. Se a rede estiver sobrecarregada, podem ser inseridos atrasos que podem atrapalhar a qualidade final da voz. Todavia, se a telefonia IP é usada em uma rede privada dedicada, a qualidade final de voz está bem próxima do nível escolhido desejado pelos clientes. 6.2 Ambiente de Telefonia IP A telefonia IP refere-se ao fluxo de voz sobre pacotes transportados sobre redes que utilizam o protocolo IP para terminais onde o fluxo é decodificado em voz novamente. Esses terminais podem tanto ser computadores quanto telefones convencionais modulados. Figura 26 Ambiente de telefonia IP A figura 26 mostra o mais simples ambiente de telefonia IP e é composto por dois usuários se comunicando sem que haja utilização de rede telefônica convencional. A codificação 76 / 123

78 da voz é feita pelos computadores envolvidos e a transmissão é feita através da rede IP. Vários softwares estão disponíveis para esta aplicação, podendo utilizar um protocolo proprietário ou padrão, permitindo a interação de softwares de diferentes fabricantes. 77 / 123

79 7 Ambiente de Validação Neste capítulo iremos analisar parte da teoria sobre o padrão H.323 dita até então na prática. Somente parte da teoria pois alguns testes não foram possíveis de serem feitos e os softwares que utilizamos não atendiam a todas especificações possíveis de serem atendidas. Criamos então vários cenários para ilustrarmos o real funcionamento do padrão H.323 entre os componentes de uma rede de videoconferência. Em cada cenário iremos analisar a troca de mensagens entre os componentes da rede de videoconferência Tentamos avaliar também ferramentas para SIP, mas fomos barrados por burocracias dos sites que disponibilizavam essas ferramentas e por mal funcionamentos de outras Nosso ambiente de validação consiste de 6 cenários: Cenário 1: dois terminais; Cenário 2: três terminais; Cenário 3: dois terminais e um Gatekeeper; Cenário 4: três terminais e uma MCU; Cenário 5: dois terminais e duas MCU; Cenário 6: três terminais, uma MCU e um Gatekeeper. Os softwares utilizados nestes cenários serão descritos a seguir. 7.1 Aplicativos Utilizados Para a validação deste projeto foram aplicados softwares freeware, ou seja, softwares que podem ser implementados em qualquer lugar sem precisar de contrato com a empresa fabricante. Como clientes escolhemos o Netmeeting de plataforma Windows e o Gnomemeeting de 78 / 123

80 plataforma Linux, pois possuem maior número de recursos (chat, transferência de arquivos, etc) em relação aos outros freeware e também por serem mais populares hoje em dia. Utilizamos a MCU e o Gatekeeper do projeto OpenH323, que tem versões em Windows e Linux. Para vermos o tráfego de mensagens utilizamos o sniffer Ethereal que tem plugin para identificar mensagens H323 e SIP. Em conjunto com o sniffer, utilizamos uma ferramenta chamada CallFlow que cria um gráfico do tráfego de mensagens do padrão H323 a partir da captura feita pelo Ethereal Netmeeting A Microsoft foi a criadora de um programa de videoconferência para plataforma Windows chamado NetMeeting. A Microsoft desenvolveu as funções de áudio e videoconferência do NetMeeting baseado na tecnologia H.323 o que o torna possível interoperar com outros produtos também baseados nesta tecnologia. O Netmeeting pode estabelecer conexões de áudio e vídeo conferência através de conexões TCP/IP. Com protocolos H.323, usuários podem se comunicar e transmitir dados de áudio e vídeo para outros usuários. Além disso, com o uso de uma MCU, o NetMeeting permite vídeo conferência entre vários usuários ao mesmo tempo. Além disso, seus codecs operam entre 4.8 Kbps e 64 Kbps suportado por vários computadores e vários tipos de conexão. Para uma maior performance, o NetMeeting especifica o H.263 e o G.723 como codecs padrão. Contudo, ele pode suportar outros codecs, como por exemplo o H.261 ou G.711, dependendo dos requisitos de outros produtos que suportam o padrão H.323. São criadas associações durante uma conferência entre o T.120 e o H.323 que faz com que uma chamada pelo NetMeeting seja completada em duas fases, uma conexão usando o T / 123

81 e outra usando o H.323. Para o usuário essas duas conexões ficam transparentes, parecendo que somente um tipo de conexão é feito. É possível operar o NetMeeting com qualquer outro produto ou serviço sobre TCP/IP que siga o padrão H.323. Dependendo da disponibilidade de codecs de áudio e vídeo compatíveis, produtos H.323 podem interoperar e trocar informações de áudio e vídeo. Existem também servidores e pontes que podem controlar conferências multipontos para produtos compatíveis ao padrão H.323. Alguns desses servidores podem controlar inclusive conferência de dados como transferência de arquivos ou compartilhamento de programas. NetMeeting foi desenvolvido para executar funções de conferência de dados baseado na infraestrutura do padrão T.120, tornando possível a interoperabilidade do NetMeeting com outros produtos baseados na tecnologia T OpenH323 O projeto OpenH323 tem como objetivo criar uma implementação completa com inúmeras funções, interoperabilidade e código fonte aberto do protocolo de videoconferência padronizado pela ITU para a utilização por desenvolvedores. O desenvolvimento do OpenH323 é coordenado por uma empresa australiana, Equivalence Pty Ltd, mas é aberto para qualquer tipo de interesse, financeiro ou não. Os programas descritos abaixo fazem parte do Projeto OpenH OpenMCU A OpenMCU Funciona como uma Unidade de Multi Conferencia (MCU Multi Conference Unit) e usa o protocolo H.323. Este programa é bem limitado e possui as seguintes funções: 80 / 123

82 Não requisita de qualquer tipo de hardware de codificação para operar; Suporta os codecs de áudio G.711, GSM MS-GSM e LPC-10; Suporta o codec de vídeo H.261; Suporta multiplas conexões simultaneamente; Várias videoconferências podem estar em funcionamento ao mesmo tempo usando as salas de videoconferencia; Mostra estatísticas de chamadas em andamento; Inicia chamadas a partir da própria MCU para Terminais; Possibilita o uso de loopback que retorna o áudio para o Terminal de origem. O OpenMCU entra em operação quando executamos o programa pelo Prompt e depois o programa fica em estado de espera por chamadas. Sempre que uma conexão é estabelecida, o OpenMCU determina a que conferência aquela chamada pertence observando a que sala o Terminal quer ser conectar. Observado isso, o sistema adiciona o Terminal àquela sala especificada. Novas salas são criadas automaticamente e também existe uma sala padrão pois existem programas, como o Microsoft Netmeeting, que não permite a escolha de uma sala específica. Esta sala padrão se chama room101. O programa possui uma limitação quanto ao vídeo, mesmo que tenha dez Terminais conectados, o OpenMCU enviará somente o vídeo de quatro usuários ativos. Estes quatro vídeos são enviados todos ao mesmo tempo e juntos numa tela dividida em quatro partes. 81 / 123

83 OpenGK O OpenGK é um Gatekeeper H.323 que ainda não está implementado para fazer grandes coisas e atualmente a única coisa que ele faz é registrar um Terminal na rede H.323. Para executarmos o OpenGK no Windows 98, digitamos no prompt do DOS opengk debug. A opção debug é para que abra uma janela e mostre o que o Gatekeeper está executando, como se fosse um tipo de log. Caso executarmos sem a opção debug, o OpenGK irá rodar por traz do Windows OpenPhone O OpenPhone é um aplicativo que segue o padrão H.323 e pode ser utilizado tanto para receber como para fazer chamadas. O aplicativo está com as implementações adiantadas, mas falta ainda alguns recursos que estão com mau funcionamento ou até mesmo faltando implementar. Algumas limitações foram decisivas para escolhermos deixar um pouco de lado o aplicativo. Uma delas é que, apesar do OpenPhone receber pacotes de vídeo, ainda não está implementada a função de enviar pacotes de vídeo. Os codecs de áudio são de péssima qualidade e são muito instáveis. Uma função que utilizaremos do OpenPhone neste projeto será a transferência de chamadas, ou seja, é possível que, a partir de um Terminal-1 com uma chamada ativa com um Terminal-2, transfira esta chamada para um Terminal-3 desocupado. E assim o Terminal-2 e o Terminal-3 se conectam e o Terminal-1 passa a ficar desocupado GnomeMeeting GnomeMeeting é um aplicativo de videoconferência para Linux compatível com o protocolo H.323. Começou a ser desenvolvido por Damien Sandras em 25 de dezembro de 2000, 82 / 123

84 como uma tese de mestrado na "Université Catholique de Louvain" na Bélgica ( O GnomeMeeting tem as seguintes características: Compatível com o protocolo H.323 Suporta tunelamento H.245, que é o envio de várias mensagens todas encapsuladas como se fossem uma só para agilizar a troca me informações Suporte aos seguintes codecs de audio: LPC10, GSM-06.10, MS-GSM, G.711-Alaw, G.711-uLaw, G.726 e, se usando um dispositivo Quicknet, o codec G Suporte aos seguintes codecs de video: H.261-QCIF et H.261-CIF Gatekeeper Desenvolvido para o o ambiente Gnome, mas é compatível também com o kde. Funciona com o Netmeeting e outros produtos compatíveis com H.323 Suporte ao T.120 não foi implementado no GnomeMeeting ainda. O GnomeMeeting focaliza mais os protocolos e características de videoconferência, mas a maioria das características do T.120 como compartilhamento e transferência de arquivos podem ser facilmente ativadas através de outras ferramentas Sniffer Ethereal O Ethereal é um analisador freeware de protocoloes de rede para Unix e Windows. Ele permite examinar dados de uma rede em funcionamento ou de pacotes previamente capturados e salvos no disco. É possível navegar interativamente pelos dados capturados, observando um resumo ou até mesmo informações detalhadas de cada pacote capturado. O Ethereal possui várias 83 / 123

85 funções, incluindo um filtro de pacotes e a habilidade de observar um fluxo de dados de uma sessão TCP reconstruído. O Ethereal está preparado para capturar mais de 325 protocolos diferentes. Com o uso de alguns plugins próprios para o Ethereal, é possível capturar protocolos que, sem o plugin, seriam desconhecidos pelo Ethereal. Utilizamos o plugin para H.323 e tornou possível a identificação de pacotes deste padrão CallFlow O CallFlow cria um gráfico mostrando as trocas de mensagens do padrão H323 entre os participantes de uma conferência. Este gráfico é feito a partir de um arquivo onde foi inserido todo o tráfego obtido através do Ethereal. Este tráfego já deve ter sido filtrado pelo sniffer inserindo no arquivo apenas as mensagens do padrão H / 123

86 8 Análise Prática cenário. Os testes e as análises dos protocolos e dos softwares estão descritos a seguir em cada 8.1 Cenário 1 Figura 27 Cenário 1: Ponto-a-Ponto De acordo com a figura 27 no primeiro cenário, temos dois terminais H.323. O terminal 1 possui o sistema operacional Windows 98 e executa o programa Netmeeting. No terminal 2 está instalado o sistema operacional Linux e o cliente H.323 é o GnomeMeeting. Neste cenário queremos demonstrar a conexão entre dois clientes H.323 de plataformas diferentes, observando os procedimentos de estabelecimento de conexão numa conferência. Para verificar as mensagens trocadas entre os terminais H.323 usamos um sniffer (Ethereal), filtrando mensagens Q.931, H.225 e H.245, e com o programa Callflow, podemos obter a figura abaixo. A figura 28 representa as trocas de mensagens para o estabelecimento e encerramento da conexão entre os terminais. Terminal 1 Terminal 2 setup > callproceeding < / 123