VoIP - Voz sobre IP
1 - Introdução
Uma revolução está para acontecer no ambiente de telecomunicação. Há décadas, desde a invenção do telefone, que a exigência básica para uma comunicação telefônica é o estabelecimento de um circuito entre os dois assinantes ou interlocutores. Isto se dá ainda hoje, na maioria das ligações telefônicas realizadas. É certo que o circuito é digitalizado e multiplexado, mas sua presença é indispensável na comunicação telefônica convencional e que representa a telefonia pública hoje utilizada, conhecida como PSTN (Public Switched Telephonic Network ou Rede Telefônica Pública Comutada).
Atualmente todas a formas de comunicação estão relacionadas com a Internet, o que provocou um crescimento no tráfego de dados em relação ao tráfego telefônico. Transportar voz em redes de dados e não dados em redes de transmissão de voz, como é tradicional, tornou-se uma solução muito atrativa.
Mas esta necessidade está acabando, com a utilização de redes de pacotes para tráfego de voz. Dentro deste conceito, a voz é empacotada e transmitida em redes compartilhadas, juntamente com dados. E agora é hora da utilização de redes IP. O protocolo que conquistou o mundo de dados com a Internet agora vai entrar também no mundo de voz. Este é o objetivo da Telefonia IP.
O termo Telefonia IP, Telefonia Internet ou ainda Voz sobre IP (VoIP - Voice over
IP) tem se aplicado na utilização de redes baseadas em protocolo IP na camada de rede para
transporte de voz, em especial a Internet. Podemos destacar as vantagens da utilização deste serviço:
• Compartilhamento da rede para o tráfego de voz com o tráfego de dados (email, www, ftp, etc);
• Unificação de redes de transporte, sinalização e gerência sobre a mesma rede, com economia de infra-estrutura e manutenção.
• Meio de transmissão de baixo custo, comparado ao sistema telefônico;
• Possibilidade de compactação e supressão de silêncio, reduzindo a largura de banda utilizada.
• Utilização de rede já instalada;
• Possibilidade de oferecer outros serviços como correio de voz, call centers via Internet, segunda linha virtual, etc.
• Possibilidade de disponibilização de diversos serviços como email, fax, voz, web, com o auxílio de tecnologias com reconhecimento e síntese de voz, através de interface telefônica.
O transporte de voz numa rede IP (VoIP - voice over IP) tem-se tornado realidade, apesar do desenvolvimento desta tecnologia ainda estar no inicio, já existem muitos fornecedores que tencionam oferecer serviços de VoIP (voice over IP). Os fabricantes de equipamentos de telecomunicações, como a Ericcson, Siemens, Nortel e Lucent e também de dispositivos para redes de dados, como o Cisco, já incorporaram as funcionalidades do VoIP nos seus produtos.
Os produtos de Hardware e Software que implementam as comunicações VoIP são úteis para empresas. Apesar de a qualidade do som ou a qualidade do serviço (QoS) ainda ser inferior à rede telefônica tradicional (PSTN- public switched telephone network), o VoIP oferece outras vantagens tais como custos inferiores para longas distâncias e uma grande flexibilidade.
Muitas empresas ainda mantêm uma rede dedicada de voz e uma rede de dados separada mas estão percebendo o valor (ex., baixo custo) da Voz sobre IP (VoIP) em redes baseadas em dados. VoIP é uma tecnologia que lhe permite fazer chamadas telefônicas e enviar faxes sobre uma rede de dados IP como se estivesse a utilizar a rede Pública Tradicional Telefônica Comutada (PSTN). Esta capacidade permite a redução dos custos de telefone e fax das empresas; converge serviços de dados, voz, fax, e vídeo; e constrói novas infrastruturas para aplicações avançadas de e-commerce (ex., Call center Web).
VoIP recebeu suporte das organizações standart, tais como a International Telecommunications Union (ITU) e a Internet Engineering Task Force (IETF) e dos distribuidores de comunicações. Hoje, pode-se encontrar produtos de VoIP no mercado e construir redes VoIP. Antes de se implementar VoIP na sua empresa deve tornar-se familiar com esta aplicação, tecnologias fundamentais, H.323 e outros padrões VoIP, e explorar várias considerações de desenvolvimento VoIP.
2. Cenários de Uso
Embora se acredite que Telefonia IP seja limitado somente para chamadas entre dois computadores, na realidade, Telefonia IP refere-se ao fluxo de voz sobre pacotes transportado sobre redes que utilizam o Internet Protocol (IP) para terminais onde o fluxo é decodificado em voz novamente. Estes terminais podem ser computadores, ou da mesma forma telefones convencionais analógicos. Neste caso, um gateway é requerido para converter os pacotes de áudio para o formato que a rede telefônica convencional utiliza.
Computador a computador
Este primeiro cenário é o mais simples e antigo da Telefonia IP. Dois usuários se comunicando sem que haja utilização da rede telefônica convencional. Vários softwares estão disponíveis para esta utilização, podendo utilizar protocolo proprietário ou padrão. Nesta última opção, podemos encontrar a interação de softwares de diferentes fabricantes. A codificação de voz é feita pelos computadores envolvidos e a transmissão é feita através da rede IP.
Computador a telefone
Neste ambiente necessitamos da utilização de um gateway, um equipamento que faz a interface entre a Telefonia IP e a telefonia pública convencional. Todos os protocolos envolvidos com a Telefonia IP terminam neste equipamento e são aí processados e resolvidos. A partir dele a rede telefônica convencional é responsável pela comunicação da voz. Ele converte voz, sinalização e controle da rede IP para a rede telefônica convencional, permitindo a comunicação entre usuários dos dois ambientes: rede IP e telefonia convencional.
Telefone a telefone
Finalmente, temos a utilização da Telefonia IP para ligação de dois assinantes da telefonia convencional. Desta forma, a rede IP é utilizada apenas como uma forma de transporte da voz, por ser uma meio mais barato. Um exemplo desta utilização é para chamadas internacionais, para redução de custos. As operadoras públicas podem também ocasionalmente substituir parte de sua rede convencional por uma rede IP
Outro engano sobre Telefonia IP é pensar que seu maior benefício seja para chamadas de longa distância de baixo custo. Enquanto ligações de longa distância baratas estão criando boas áreas de trabalho, as razões pelas quais as companhias são atraídas para a Telefonia Internet são a facilidade de criação de serviços e a consolidação de suas redes.
Assim, a principal vantagem de VoIP sobre a Rede Telefônica Pública Comutada (RTPC) é a facilidade de adição de novos serviços e funcionalidades. Por exemplo pode-se criar uma vídeo-conferência pela definição de como o fluxo de vídeo é codificado e decodificado. Ao contrário, fazer vídeo-conferência sobre a RTPC pode ser um processo difícil e caro. Da mesma forma, como Telefonia IP é baseado em software e é mais fácil adicionar serviços como correio de voz, siga-me e outros.
Uma segunda vantagem para a Telefonia IP é a consolidação das redes de dados. Atualmente, companhia 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.
Podemos ainda prever a integração de diversos serviços sobre o sistema telefônico, utilizando de tecnologias agregadas como reconhecimento e síntese de voz. Por exemplo, é possível ouvir todos os emails recebidos por um telefone comum, utilizando a síntese de voz e transmissão sobre IP para que estes emails cheguem sobre um telefone comum. Desta mesma forma, serviços como fax, web e outros podem ser acessados através de telefones comuns.
Podemos prever ainda, a unificação de três redes hoje existentes para a 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 de telefonia IP, unifica-se todas estas redes sobre a mesma infra-estrutura e utilizando sempre o mesmo protocolo de rede: IP.
Um último engano sobre VoIP é sobre sua 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 Telefonia IP é usada em uma rede privada dedicada, com garantia de QoS, a qualidade final de voz está bem próxima do nível escolhido pelos clientes.
3 - Aspectos de tráfego de voz em tempo real
3.1 - Atraso na Telefonia IP
Em um sistema de telefonia IP, vários fatores afetam a qualidade acústica final ao usuário. Um grande fator característico da qualidade é o atraso da voz, desde o momento em que é pronunciada até o momento em que é reproduzida. Muitos fatores atuam no sentido de aumentar este atraso, os quais vamos então discutir.
O atraso tem influência direta na qualidade de serviço da telefonia sobre IP. O usuário do sistema percebe um intervalo entre suas interlocuções igual a duas vezes ao atraso. Isto se dá porque o seu interlocutor só perceberá o fim da sua fala depois de um tempo igual ao atraso, e só depois começará a falar. Como sua fala também terá um atraso igual ao anterior, o usuário terá a impressão de atraso em dobro. A este tempo dá-se o nome de round-trip, que corresponde a duas vezes o atraso.
A ITU-T define da seguinte forma os valores em milissegundos para o atraso:
A telefonia convencional tipicamente não inclui atrasos maiores do que 150 milissegundos, o que é imperceptível para o homem. Ligações internacionais, principalmente quando envolvem satélites, podem ter atrasos de até 1 segundo, o que é considerado inaceitável para manter uma boa interlocução.
3.2 Entendendo o atraso
O atraso percebido num ambiente de telefonia IP, é gerado por uma série de pequenos atrasos:
• Atraso de formação do pacote: Tempo necessário para o preenchimento do pacote de voz a ser enviado. Os pacotes de voz são determinados pelo tamanho do vetor ou célula gerada pelo vocoder multiplicado pelo número de células que compõe este pacote. Atrasos médios são da ordem de 20 a 30 ms para a formação de uma célula. A maioria dos sistemas utiliza apenas uma célula por pacote, o que pode reduzir a
eficiência do sistema, visto que o conteúdo útil do pacote é reduzido em relação ao tamanho total do pacote.
• Atraso de rede: Tempo necessário para o transporte pela rede do pacote do terminal origem até o terminal destino. É um tempo variável e que pode comprometer o sistema. Este tempo é a soma do tempo gasto em todos os roteadores da rede, além dos sistemas de transmissão dos próprios terminais.
Sempre existe um processo de formação do pacote e outro correspondente para reprodução da voz. Estes dois podem acontecer no computador de origem e/ou destino ou então num gateway correspondente que faz a interface com uma rede de telefonia convencional.
A figura a seguir ilustra esta situação e mostra os reponsáveis pelos atrasos.
3.3 Jitter
É interessante observar no atraso de rede, que seu valor varia muito em função do ambiente e ao longo do tempo, sendo impossível dimensioná-lo se estiver baseado nas redes IP convencionais. Se todos os pacotes recebessem o mesmo atraso, este atraso seria propagado integralmente sobre a voz e seria o atraso final da voz.
O problema é a variação deste atraso. Como os pacotes chegam com diferentes atrasos, estes pacotes não podem reproduzir a voz diretamente ao usuário, pois, desta forma a voz sofreria cortes em função de atrasos maiores. A variação do atraso é conhecida como jitter.
O jitter deve ser tratado para evitar efeitos indesejáveis sobre a voz. Se a voz fosse reproduzida de forma instantânea, ela ficaria extremamente dependente do jiiter. Por exemplo, se cada pacote representa 35 ms do fluxo de voz, eles deveriam chegar ao terminal com intervalo de 35 ms. Porém, graças ao efeito da rede, este intervalo varia,
alguns pacotes podem chegar atrasados, resultando na interrupção da voz. Outros pacotes podem ainda chegar num intervalo menor, que gera uma sobreposição da voz.
Para a manutenção do fluxo de voz, é necessário um armazenamento de pacotes por um tempo superior ao maior jitter observado. Como não existe previsão do valor do jitter em função inclusive da possível perda de pacotes, estima-se um valor médio para criação deste armazenamento. Este processo é chamado de supressão de jitter e como já foi observado, este armazenamento gera um atraso chamado atraso de supressão de jitter.
3.4 Controlando o Atraso
Controlar o atraso é o ponto chave na tecnologia de Telefonia IP para permitir seu uso em larga escala. A solução prevê sua utilização em redes cujo tráfego seja conhecido e controlado. Algumas medidas podem ser tomadas no sentido de controlar a rede e assim o atraso:
• Uso de equipamentos de rede que possibilitem um controle de qualidade de serviço, seja ele através da priorização de pacotes ou através da reserva de recursos na rede;
• Garantir que a rede tem largura de banda suficiente para o tráfego observado. Algumas ferramentas de medição de tráfego podem ser usadas neste sentido; • Verificar a disponibilidade de banda a cada instante, bem como a taxa de
perdas e de erros e permitir a mudança dinâmica de vocoder utilizado, de forma a se adaptar às condições da rede. Alguns equipamentos já permitem esta mudança dinâmica;
• Verificar o atraso nos equipamentos que estão fora de controle da rede, como a Internet pública, por exemplo e se necessário alterar a velocidade dos enlaces para a Internet e a empresa fornecedora do serviço.
• Aumentar a eficiência dos pacotes, utilizando, se possível dois ou mais canais por pacote. Isto pode reduzir o tráfego da rede em até 50%.
4 - Padrões para Telefonia IP
Para realizar uma chamada são necessários protocolos de controle e sinalização para execução de algumas tarefas como localização do usuário a ser chamado, notificação de chamada, notificação de aceite da chamada, início da transmissão de voz, finalização da transmissão de voz e desconexão. Isto sem considerar os serviços adicionais no ambiente de telefonia. Inicialmente estas tarefas eram executadas por protocolos proprietários, hoje, dois conjuntos de protocolos padrões dominam o cenário de telefonia.
A maioria dos protocolos de sinalização estão focadas na conexão e no controle da chamada, que estão separados da transmissão de conteúdo multimídia (voz) entre os terminais. Isto porque a conexão e o controle de chamada podem envolver terceiros elementos, como um servidor de localização. Desta forma, permite-se que os terminais transmitam a voz sem a intervenção deste terceiro elemento.
Vários soluções proprietárias foram utilizadas para transmissão de voz em redes IP. Porém estas soluções não garantiam interoperabilidade entre os equipamentos. Podemos verificar então, o advento de dois padrões que podem ser utilizados para garantir a interoperabilidade entre sistemas de Telefonia IP. O padrão H.323, proposto pela ITU-T e o padrão SIP proposto pelo IETF .
Independente do padrão utilizado, o protocolo normalmente utilizado para transmissão do fluxo de voz é o Real Time Protocol (RTP). RTP por sua vez utiliza de
User Datagram Protocol (UDP) para transmitir estes pacotes. RTP é feito sobre UDP
porque a velocidade é necessária e fundamental no processo e a perda de pacotes pode ser compensada no processo de codificação e decodificação da voz.
Para garantir a comunicação entre terminais na Internet e telefones analógicos presentes na rede telefônica convencional, os protocolos devem ser capazes de interagir com os equipamentos nesta rede. Esta interconexão é efetuada por um gateway. Um
gateway é responsável por converter comandos do protocolo de controle baseados em IP
para protocolos tradicionais de sinalização como SS7 e ISDN, além de converter o fluxo de voz para sinais de voz compatíveis com a rede telefônica convencional.
4.1 Real Time Protocol (RTP)
RTP (Real time transport protocol) é um protocolo padrão para transporte de dados com características de tempo real, como vídeo e áudio, que pode ser usado em serviços tanto como mídia sob demanda quanto interativos, do tipo telefonia IP. É composto por uma parte de transmissão de dados e outra de controle, chamada RTCP (Real Time Control
Protocol). A parte de dados consiste de um protocolo leve, que provê suporte para
mensagens, detecção de perdas, segurança, selo de tempo e identificação de conteúdo. RTCP é usado para monitorar a qualidade de serviço da transmissão e para transmitir informações sobre os participantes de dada sessão. Apesar do RTP utilizar serviços do UDP e IP, ele pode ser implementado em outros ambientes, já que necessita somente de serviço de transporte não orientado à conexão.
O processo de transporte envolve acompanhar o fluxo de bits gerados pelo codificador de mídia, normalmente o vocoder de Telefonia IP, quebrando em pacotes, enviando os pacotes pela rede e reproduzindo o fluxo de bits no receptor. O processo é complexo porque pacotes podem ser perdidos, receber 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ções para o atraso.
Para ajudar nestas funções, RTP define o formato de pacote que trafega pela rede. O pacote contém informação sobre a mídia, chamada RTP Payload, junto ao cabeçalho RTP. Este cabeçalho provê informações para o receptor que permitirão a reconstrução da mídia. RTP também especifica como o fluxo de bits do vocoder estão agrupados nos pacotes. RTP contém também dispositivos para multicast, permitindo seu uso em aplicações de conferência e ambientes broadcast usados para distribuição de mídia. É importante notar que RTP não tenta reservar recursos na rede para evitar perdas de pacotes e atrasos, ele apenas permite ao receptor notar a presença desta perda e do atraso.
RTP é componente chave dentro de sistemas de Telefonia IP. Podemos verificar que além do SIP, o próprio padrão H.323 faz uso do RTP, de forma que podemos considerá-lo universal para uso de Telefonia IP.
Podemos verificar algumas funcionalidades do RTP:
- Seqüenciamento: Atribui número de ordem aos pacotes. Isto pode ser usado para verificação de perdas e possível reordenamento de pacotes;
- Identificação de conteúdo: Em redes sem garantia de QoS, como a Internet e redes de computação móvel, condições de perda de pacotes e atraso podem variar ao longo do tempo. Podemos observar que diferentes vocoders apresentam diferentes características de qualidade final em função das perdas e atrasos. Este campo permite a alteração dinâmica do vocoder utilizado em função das perdas e do atraso a fim de melhorar a qualidade final acústica.
- Identificação de quadro: Os quadros são unidades básicas de transmissão dos vocoders. Um pacote pode conter vários quadros. RTP marca o início e o fim de cada pacote, necessário para identificação deste quadro.
- Identificação de origem: Necessária para indicar quem enviou o pacote. Isto porque em uma conferência multicast um mesmo fluxo pode ter várias origens.
Já o RTCP, que acompanha o RTP, que provê informações adicionais sobre seus participantes:
- Retorno de informações de Qualidade de Serviço: Receptores podem retornar informações sobre atraso, jitter e perdas, que pode ser usadas para adaptar a aplicação como por exemplo alterar o vocoder que está sendo utilizado.
- Sincronismo Intermídia - Necessário para sincronizar diferentes fluxos, como áudio e vídeo, caso sua origem seja de servidores diferentes.
- Identificação do usuário: Email, Nome, Organização, número telefônico, etc. RTCP necessita que todos os participantes enviem estas informações periodicamente. RTCP usa o mesmo endereço do RTP, porém usa uma porta diferente. Nem todas as aplicações RTP utilizam RTCP, que não é indispensável para as aplicações.
4.2 - SIP - Session Initiation Protocol
O SIP foi concebido na Universidade de Columbia e depois submetido para aprovação do IETF (Internet Engineering Task Force). Como outros protocolos dominantes na Internet (HTTP, FTP, SMTP), SIP é baseado em texto. SIP foi aprovado como RFC (Request For Comment), sendo publicado como RFC 2543, em março de 1999.
SIP preocupa-se com a sinalização e não tenta definir qualquer aspecto de comunicação multimídia, como H.323 faz. Consequentemente, ele pode ser documentado em menos que 130 páginas de leitura relativamente fácil. SIP reutiliza algumas características de outros protocolos, como por exemplo, os mesmos cabeçalhos, erros e regras de codificação do HTTP.
O protocolo de sinalização SIP inicia uma sessão entre usuários. É usado para serviços de localização de usuários, controle de chamada e gerência de participantes em uma conferência (usando uma extensão SIP). SIP não define o tipo de sessão que é estabelecida, de forma que pode ser facilmente usado tanto para estabelecer sessões de jogos como para estabelecer conferências de vídeo/áudio.
Cada requisição SIP consiste de um conjunto de campos de cabeçalho que descrevem a chamada seguidos por uma mensagem que descreve uma sessão individual que está sendo realizada na chamada. Normalmente é usado, mas pode ser negociado outro protocolo. Além disto, como SIP não define todo o potencial do protocolo usado em comunicações multimídia, ele deve ser combinado com outro protocolo IETF para criar uma solução completa. Por exemplo, você pode usar as características de tocar e gravar do
Real Time Streaming Protocol (RTSP) para prover funcionalidades de voicemail ou
SIP é um protocolo cliente-servidor, parecido tanto em sintaxe como semântica ao protocolo HTTP. Requisições são geradas por uma entidade cliente e enviadas para uma entidade receptora ou servidor. O servidor processa a mensagem e então envia uma resposta para o cliente. A requisição e a resposta que chegam a seguir são chamadas transações. Todo software SIP tem um sistema final que interage com um usuário conhecido como User Agent. Um user agent tem dois componentes, um user agent client(UAC) e um user agent server(UAS). O UAC é responsável por iniciar as chamadas, enviando requisições, e o UAS é responsável por responder às chamadas, enviando respostas. Uma aplicação de telefonia Internet contém ambos UAC e UAS. Vale destacar a diferença com um Web Browser que contém apenas um cliente.
Com funções específicas, espalhados pela rede, existem três tipos de servidores. Servidores de registros, os quais recebem atualizações sobre a localização corrente de cada usuário; servidores proxy, os quais recebem requisições e enviam-nas para outros servidores, conhecidos então como servidores next-hop. O servidor next-hop pode ser outro servidor proxy, um UAS ou um servidor de redirecionamento. Um servidor de redirecionamento também recebe requisições e determina um servidor next-hop. Todavia, ao contrário de reenviar a requisição neste caso, ele retorna o endereço do servidor next-hop para o cliente. A função primária dos servidores proxy e de redirecionamento são roteamento de chamadas, ou seja a determinação do conjunto de servidores a serem usados no caminho para completar a chamada. Um servidor proxy ou um servidor de redirecionamento pode usar qualquer meio para determinar o servidor next-hop, incluindo executar programas e consultar bancos de dados. Um servidor proxy pode também duplicar uma requisição, enviando cópias para múltiplos servidores next-hop de uma vez. Isto permite que uma requisição de ínicio de chamada tente diversas localizações diferentes ao mesmo tempo. A primeira localização que responder é conectada com o cliente chamador.
Como no HTTP, o cliente requisita a chamada de métodos ou comandos no servidor. SIP define muitos métodos. INVITE convida um usuário para uma chamada. BYE termina uma conexão entre dois usuários em uma chamada. OPTIONS solicita informações sobre as capacidades, mas não configura uma chamada. ACK é usado para confirmar mensagens trocadas para estabelecimento. CANCEL termina a procura por um usuário. Finalmente REGISTER adiciona informações sobre um usuário para um servidor de registro.
Um cliente inicia uma chamada enviando uma requisição INVITE. Esta requisição contém campos de cabeçalho usados para levar informações sobre a chamada. Os campos de cabeçalho mais importante são TO e FROM, os quais contém o endereço do chamador e do chamado. O campo SUBJECT identifica o assunto da chamada. O campo CALL-ID contém um identificador único da chamada e o campo CSEQ contém um número de seqüência. O campo CONTACT lista endereços onde o usuário pde ser contactado. Este último é colocado em respostas de um servidor de redirecionamento, por exemplo. O campo REQUIRE é usado para a negociação do protocolo a ser utilizado como extensão ao SIP. Os campos CONTENT_LENGTH e CONTENT-TYPE são usados para levar informações sobre o conteúdo da mensagem. No conteúdo da mensagem vemos ainda a descrição da sessão que será estabelecida.
Extensões podem ser definidas com novos campos. Uma extensão, usada para controle de chamada, incluem novos cabeçalhos para tarefas como transferências de chamadas e conferências com várias pessoas
4.2 - H.323
O H323 é uma recomendação que proporciona as bases para a transmissão de áudio, vídeo e comutação de dados, através das redes baseadas no IP. O H323 é uma recomendação da ITU (International Telecomunications Union) que serve como modelo para comunicações multimídia através de uma LAN (Local Area Network) que não garantem qualidade de serviço (QoS). Foi inicialmente desenvolvida para conferencias multimídia nas LANs, mas mais tarde foi estendida para cobrir transmissões de voz numa rede IP.
A primeira versão foi lançcada em 1996. Este standard engloba comunicações ponto-a-ponto e conferencias multiponto. Os produtos e aplicações dos diferentes vendedores podem interagir se estiverem cobertos pela especificação H323.
Novos requisitos, tais como comunicações entre um PC-baseado em telefone e um telefone tradicional, comunicação de voz entre dois usuários de PC por meio da Internet, autenticação de chamadas e autorização, influenciaram o desenvolvimento da segunda versão do H.323 em janeiro de 1998. Em 2000 foi lançado o padrão H.323 versão 3, que incluía características tais como fax sobre redes de pacotes, estabelecimento rápido de chamadas, e comunicação entre gatekeepers. Atualmente o padrão encontra-se na sua versão 4, lançado em novembro de 2001.
H.323 é parte da família padrão H.32x do ITU. Outros padrões H.32x determina comunicações multimídia sobre outros tipos de rede (ex., H.320 para ISDN, H.321 e H.310 para Broadband ISDN - B-ISDN, H.322 para LANs que garantam QoS, e H.324 para redes de circuitos comutados. A PSTN é uma rede de circuito comutada.)
A recomendação H.323 tem como uma de suas características a flexibilidade, pois pode ser aplicada tanto a voz, quanto a vídeo conferência multimídia, entre outros. Aplicações H.323 estão se tornando populares no mercado corporativo por várias razões, dentre elas podemos citar:
· O H.323 define padrões de multimídia para uma infra-estrutura existente, além de ser projetada para compensar o efeito de latência em LANs, permitindo para que os clientes possam usar aplicações de multimídia sem mudar a infra-estrutura de redes. · As redes baseadas em IP estão ficando mais poderosos, além da largura de banda para redes com arquitetura Ethernet estarem migrando de 10 Mbps para 100 Mbps, e a Gigabit Ethernet está fazendo progressos no mercado.
· PCs estão se tornando plataformas de multimídia mais poderosas devido a
processadores mais rápidos, conjunto específicos de instrução e chips aceleradores multimídia poderosos.
· H.323 provê padrões de interoperabilidade entre LANs e outras redes.
· O fluxo de dados em redes pode ser administrado. Com o H.323, o gerente de rede pode restringir a quantia de largura de banda disponível para conferências. O suporte a comunicação Multicast também reduz exigências de largura de banda. · A especificação H.323 tem o apoio de muitas empresas de comunicações e organizações, incluindo Intel, Microsoft, Cisco e IBM. Os esforços destas companhias estão gerando um nível mais alto de consciência no mercado.
Benefícios da Especificação
Padrões de Codec – H.323 estabelece padrões para compressão e descompressão de dados de áudio e vídeo, assegurando que equipamentos de fabricantes diferentes tenham uma área de apoio comum.
Interoperabilidade - Usuários necessitam se comunicar sem se preocupar com a velocidade. Além de assegurar que o receptor pode descompressar a informação, o padrão H.323 estabelece métodos para que os clientes que recebem os dados possam se comunicar equalizando velocidades com o remetente. O padrão também estabelece ligação de chamada comum e protocolos de controle.
Independência entre Redes - O H.323 é projetado para rodar em cima de arquiteturas de redes comuns. Como a tecnologia de redes evolui, e como técnicas de administração de largura de banda melhoram, as soluções baseadas no H323 poderão tirar proveito dessas velocidades aumentadas.
Independência de Plataforma e Aplicação - O H.323 não está amarrado a um hardware ou sistema operacional. As plataformas H.323 estarão disponíveis em muitos tamanhos e formas, incluindo computadores pessoais habilitados para vídeo conferência, plataformas dedicadas e TVs a cabo.
Suporte Multiponto - Embora o H.323 possa apoiar conferências de três ou mais usuários sem requerer uma unidade de controle multiponto (MCU), este pode definir uma arquitetura mais poderosa e flexível para ser gerente de conferências de multiponto.
Administração de Largura de Banda - Tráfego de vídeo e áudio demandam alta largura de banda, o que poderia congestionar uma rede corporativa. Gerentes de redes podem limitar o número de conexões simultâneas H.323 dentro da rede, ou até mesmo a largura de banda disponível para aplicações H.323. Estes limites asseguram que um tráfego crítico não será rompido.
Flexibilidade - Uma conferência H.323 pode incluir usuários com tecnologias diferentes. Por exemplo, um terminal somente com capacidade de áudio pode participar em uma conferência com terminais que têm capacidades de dados e/ou vídeo. Além disso, um terminal multimídia H.323 pode compartilhar dados de uma vídeo conferência com um terminal de dados T.120, enquanto compartilhando voz, vídeo e dados com outros terminais H.323.
Conferência Inter Redes - Muitos usuários querem uma conferência de uma LAN para uma rede distante. Por exemplo, o H.323 estabelece meios de unir sistemas de mesa baseados em LAN com sistemas de grupo baseados em ISDN. Usuários de H.323 usam tecnologia de codec comum para padrões de vídeo conferência diferentes para minimizar a demora e prover bom desempenho.
4.2.1 Componentes do H323
O H.323 define quatro componentes lógicos: Terminais, Gateways, Gatekeepers e Multipoint Control Units (MCUs).
Terminais, gateways and MCUs são conhecidos como endpoints.
a) Terminais
Os terminais são os clientes (endpoints) que provem comunicação multimídia bidirecional em tempo real. Ele suporta a comunicação de áudio e pode opcionalmente suportar a comunicação de vídeo e dados.
Terminais são representados pelas estações cliente da rede que provêem comunicação em tempo-real e em duas direções. A Figure abaixo descreve os componentes de um terminal. Todos os terminais têm que apoiar comunicações de voz; vídeo e dados são opcionais. O H.323 especifica os modos de operação requeridos para que diferentes terminais de áudio, vídeo e/ou dados trabalhem juntos. Acredita-se que o H.323 seja o padrão dominante da próxima geração de telefones de Internet, terminais de áudio conferência, e tecnologias de vídeo conferência.
Todos os terminais H323 têm que suportar: H245,
Q931,
Registration Admission Status (RAS) e o Real Time Transport Protocol (RTP).
O H245 serve para autorizar o uso dos canais, o Q931 é utilizado para a sinalização da chamada e para o estabelecimento desta, o RTP é o protocolo que transporta pacotes de voz e o RAS é usado para a comunicação com o gatekeeper. Os terminais H323 também incluem T120-protocolos de conferencia de dados, vídeo e codecs e apoio ao MCU. Podem também comunicar-se com outro terminal H323, um Gateway H323 ou um MCU.
b). Gateways
Um Gateway H.323 é um endpoint que provê comunicação bidirecional em tempo real entre terminais H.323 e outros terminais padrão ITU (telefones comuns), ou outro gateway h.323. Os Gateways normalmente têm as seguintes funções:
• Função de procura
Quando um gateway IP é usado para estabelecer uma chamada numa rede IP, recebe um numero de telefone do destinatário e o Gateway converte-o num endereço IP,
possivelmente através de uma procura numa tabela no Gateway de origem ou então num servidor de correspondência centralizada
• Função de ligação -O Gateway de origem estabelece a ligação para o Gateway de destino, troca sinalização de chamadas, e compatibiliza a informação.
• Função de digitalização - Os sinais analógicos dos telefones são convertidos para digitais no gateway, e vice-versa.
• Função de compressão - O sinal é de voz, normalmente é comprimido pelo DSP, aplicando o standard G723.1 ou G729.
O Gateway é um elemento opcional em uma conferência H.323. Gateways provêem muitos serviços, onde o mais comum provê uma função de tradução entre os terminais de conferência H.323 e outros tipos terminais.
Gateways não são requeridos se não são necessárias conexões para outras redes, isto é, desde que as estações possam se comunicar diretamente com outras estações. Terminais se comunicam com Gateways que usam os protocolos H.245 e Q.931.
c) Gatekeepers
Um gatekeeper pode ser considerado o cérebro da rede H.323. Ele é o ponto de foco para todas as chamadas dentro da rede H.323. Embora eles não sejam necessários os gatekeepers fornecem serviços importantes tais como:
• Tradução de endereços
O gatekeeper mantém um banco de dados dos endpoints associados a sua zona (área de cobertura de um gatekeeper). Em caso de pedido de endpoint, ele traduz pseudônimos (por exemplo, hostname, endereços de email) para endereços de rede (endereço IP). Também traduz endereços externos (números de telefone) para endereços de rede.
• Controle de admissão
Consiste na autorização ao acesso à “zona” para endpoints H.323. Para tanto, utiliza requisitos de admissão ou confirmação/rejeição de mensagens. O acesso é baseado em autorização de chamadas, largura de banda além de outros critérios.
• Gestão da largura de banda
Alocação de largura de banda, confirma e rejeita mensagens ou então uma função nula que aceita todos os pedidos de mudança de largura de banda.
• Gestão de zona
O gatekeeper fornece as funções acima descritas para terminais, MCUs e Gateway que estão registados na sua zona de controle.
Um Gatekeeper é o componente mais importante de uma rede H.323. Ele age como o ponto central para todas as chamadas dentro de sua zona e provê serviços de controle de chamada para estações registradas.
Gatekeepers executam duas funções de controle de chamada importantes. A primeira é tradução de endereço dos apelidos de terminais de rede e gateways para endereços IP ou IPX, como definido na especificação da RAS. A segunda função é administração de largura de banda, que também é designada dentro da RAS. Por exemplo, se um gerente de rede especificou um limite para o número de conferências simultâneas na rede, o Gatekeeper pode recusar fazer mais algumas conexões uma vez que o limite é alcançado. O efeito é limitar a largura de banda total da conferência, para alguma fração do total disponível; a capacidade restante permanece para e-mail, transferência de arquivo, e outras atividades da rede. A coleção de todos os Terminais, Gateways e MCUs
administrados por um único Gatekeeper é conhecida como uma Zona H.323 e mostrado na Figura abaixo.
Um opcional, mas valiosa característica de um gatekeeper, é sua habilidade para rotear chamadas H.323. Pelo roteamento de uma chamada através de um gatekeeper, um serviço pode ser controlado mais efetivamente. Provedores de Serviço precisam desta habilidade para faturar as chamadas registradas pela suas redes. Este serviço também pode ser usado para redirecionar uma chamada para outra estação se uma estação chamado está indisponível. Além disso, o gatekeeper é capaz de rotear chamadas H.323 podendo ajudar nas decisões que envolvam balanceamento entre gateways múltiplos. Por exemplo, se uma chamada é roteada por um gatekeeper, este gatekeeper pode redirecionar a chamada para um dos muitos gateways baseados em alguma lógica de roteamento proprietária.
Gatekeepers também podem representar um papel em conexões multiponto. Para apoiar conferências de multiponto, usuários empregariam um Gatekeepers para receber Canais de Controle H.245 de dois terminais em uma conferência de ponto-para-ponto. Quando a conferência troca para multiponto, o gatekeeper pode redirecionar o Canal de Controle H.245 para um Controlador Multiponto, o MC. O Gatekeeper não necessita processar a sinalização H.245; só precisa passar ela entre os terminais ou entre os terminais e o MC.
d). Multipoint Control Units (MCU)
O MCU é um endpoint numa rede, e proporciona a participação de três ou mais terminais e Gateway numa conferencia multiponto. O MCU é constituído por um controlador multiponto (MC) que é obrigatório e um processador multiponto (MP) que é opcional.
O MC determina as capacidades dos terminais usando o H.245, mas não executa a multiplexagem de áudio, vídeo e dados. A multiplexagem do fluxo de dados multimídia é da responsabilidade do MP sob o controle do MC. O MC não trata diretamente qualquer tipo de fluxos de mídia. Isto é atribuição do MP que mistura, chaveia, e processa áudio, vídeo e/ou bits de dados. Facilidades MC e MP podem existir em um componente dedicado ou podem ser parte de outros componentes H.323.
Conferências Multipontos são dirigidas para uma variedade de métodos e configurações H.323. A Recomendação usa os conceitos de conferências centralizadas e descentralizadas, como mostrado na Figura abaixo.
4.2.2. Stack de protocolos do H.323
A figura seguinte ilustra a stack de protocolos do H.323. Áudio, vídeo e pacotes de registro usam o UDP (User Datagram Protocol) enquanto que os dados e pacotes de aplicações de controle usam o TCP (Transmission Control Protocol) como protocolo de transporte. O protocolo T.120 é usado na definição de conferencia de dados.
4.2.3. Controle e sinalização do H.323
O H.323 possui protocolos do controle H.225.0/Q.931 para sinalização das chamadas e o H.245 para controle dos dados multimídia.
Para o estabelecimento de uma chamada desde o emissor ate ao receptor, o H.225 RAS (Registration, Admission and Signaling) é usado, depois da chamada estar estabelecida, o H.245 é usado para negociar o fluxo de dados multimídia.
4.2.3.1 H.225.0 : RAS
O canal RAS é usado para estabelecer a comunicação entre os clientes finais (endpoints) e o gatekeeper. Como as mensagens RAS são enviadas no UDP (não orientado à conexão), então são estabelecidos timeouts. Os procedimentos definidos pelo canal RAS são:
a. Descoberta do Gatekeeper
Este é o processo que um cliente final usa para saber qual o gatekeeper no qual tem que se registar.
O cliente final manda uma mensagem multicast que se chama Gatekeeper Request (GRQ) que pergunta qual é o seu gatekeeper,
um ou mais gatekeepers respondem com a mensagem Gatekeeper Confirmation (GCF), indicando a disponibilidade para ser o gatekeeper para aquele cliente final,
os gatekeepers que não queiram fazer o registo dos clientes finais mandam uma mensagem de rejeição Gatekeeper Reject (GRJ) .
A mensagem de aceitação do cliente final por parte do gatekeeper inclui o endereço de transporte para o canal RAS do gatekeeper. Depois o endpoint regista-se num dos gatekeepers. Se nenhum gatekeeper responder durante um determinado espaço de tempo (timeout), o endpoint tem de retransmitir a mensagem (GRQ.)
b. Registo do Cliente final (endpoint)
Este é o processo pelo qual um cliente final se integra numa zona e informa o gatekeeper sobre o seu endereço de transporte e do endereço alias, todos os endpoints são registrados no gatekeeper que descobriram através do processo anteriormente descrito. O registro é feito por um pedido ao gatekeeper- Registration Request (RRQ), que é enviado para o canal RAS de transporte de endereço do gatekeeper. O endpoint tem o endereço de rede de gatekeeper obtido através do processo de descoberta do gatekeeper e
usa o identificador TSAP do canal RAS. O gatekeeper responde com a confirmação do registo-Registration Confirmation (RCF) ou uma rejeição do registo- Registration Reject (RRJ). O gatekeeper tem que assegurar que cada endereço alias é transformado num único endereço de transporte.
Um cliente final pode cancelar o seu registo ao enviar o respectivo pedido-Unregister Request (URQ), e o gatekeeper responde com a confirmação-pedido-Unregister Confirmation (UCF). Um gatekeeper também pode cancelar o registo de um endpoint, enviando uma mensagem- Unregister Request (URQ), e o endpoint responde com a mensagem- Unregister Confirmation (UCF) message
c. Localização de um cliente final (endpoint)
Um cliente final ou um gatekeeper que têm um endereço alias para um endpoint e gostariam de determinar a sua localização poderão enviar um pedido de localização- Location request (LRQ). O gatekeeper aonde o endpoint está registado responde com a mensagem de confirmação da localização- Location Confirmation (LCF), contendo a informação de localização do endpoint ou o gatekeeper do endpoint
d. Alocação de largura de banda e admissões
O canal RAS é também usado para a transmissão de admissões e mudanças de largura de banda. Estas mensagens são trocadas entre um endpoint e um gatekeeper e usadas para a o controle da admissão e gestão da largura de banda. Os pedidos de admissão (ARQ) especificam o pedido de alocação de largura de banda. Um endpoint ou um gatekeeper podem modificar a largura de banda de uma chamada usando o respectivo pedido- Bandwidth Change Request (BRQ)
4.2.3.2 Sinalização da chamada H225.0
a) O canal de sinalização
É usado para transportar mensagens de controle H.225, em redes que não contenham um gatekeeper. As mensagens de sinalização da chamada passam diretamente do emissor para o receptor usando o endereço de transporte de sinalização de chamadas- Call Signaling Transport Addresses. Em redes em que existe o gatekeeper a troca de mensagens é entre o endpoint receptor e o gatekeeper usando o RAS do gatekeeper. A chamada de sinalização é feita por cima do TCP.
b) Canal de endereçamento de sinalização da chamada
Mensagens de sinalização de chamadas são descritas de duas maneiras: a primeira é quando o gatekeeper encaminha as mensagens de sinalização de chamadas, através dos endpoints; a segunda alternativa é sinalização da chamada direta (Direct Endpoint Call Signaling) onde a mensagem é passada diretamente entre os endpoints. As admissões são trocadas com o gatekeeper através do canal RAS, seguidas de uma troca de mensagens de sinalização de chamadas no canal de sinalização de chamadas, tudo isto é possível pela aplicação do H.245 para controle do canal.
c) Endereçamento do canal de controle
Existem 2 métodos para endereçar este canal de controle (H.245), o primeiro é diretamente entre os endpoints, enquanto que o segundo caso é através do gatekeeper.
4.2.3.3 H.245 Controle dos dados multimídia
H.245 é o protocolo de controle dos dados multimídia que o sistema H.323 usa após o estabelecimento de uma chamada ter sido concluído. H.245 é usado para negociar e estabelecer todos os canais multimídia transportados pelo RTP/RTCP. As funcionalidades oferecidas pelo H.245 são:
1. Determinar o master e slave: H.245 nomeia um controlador multiponto-(Multipoint Controller (MC)), que é o responsável pelo controle central nos casos em que a chamada é estendida a uma conferencia.
2. Troca de capacidade: H.245 é usado para negociar capacidades, quando uma chamada é estabelecida. Esta capacidade pode acontecer a qualquer momento durante uma chamada, e pode ser alterada da mesma forma.
3. Canal de controle multimídia: Depois de clientes finais de uma conferencia terem trocado capacidades, estes podem abrir e fechar canais multimídia, estes canais são canais lógicos (são apenas identificadores)
4. Controle de conferencias: Nas conferencias o H.245 fornece aos endpoints conhecimento mutuo e estabelece o fluxo de dados multimídia entre os endpoints
4.2.4. Estabelecimento de uma chamada no H.323
Esta seção descreve os passos envolvidos na criação de uma chamada H.323, a comunicação multimídia e a liberação da chamada. Este exemplo contem dois terminais H.323 (T1 e T2) conectados a um gatekeeper. Neste exemplo considera-se o uso modelo de chamada direta e que os fluxos multimídia utilizam o RTP. A Figura abaixo ilustra o estabelecimento da chamada H.323.
(1) T1 envia uma mensagem RAS ARQ no canal RAS para o gatekeeper para registro. T1 solicita o uso do modelo de chamada direta.
(2) O gatekeeper confirma a admissão de T1 pelo envio de ACF para T1. O gatekeeper indica no ACF que T1 pode usar o modelo de chamada direta.
(3) T1 envia uma mensagem de configuração de sinalização de chamada H.225 para T2 solicitando uma conexão.
(4) T2 responde com uma mensagem H.225 call proceeding para T1.
(5) T2 envia uma mensagem RAS ARQ para se registrar no gatekeeper através do canal RAS.
(6) O gatekeeper confirma o registro pelo envio de uma mensagem RAS ACF para T2. (7) T2 alerta T1 do estabelecimento da conexão pelo envio de uma mensagem de alerta
H.225.
(8) Então T2 confirma o estabelecimento da conexão pelo envio de uma mensagem conexão H.225, e a chamada é estabelecida.
Estabelecida a chamada, ocorre a sinalização de controle entre T1 e T2 (chamada direta).
(9) O canal de controle H.245 é estabelecido entre T1 e T2. T1 envia uma mensagem H.245 TerminalCapabilitySet para T2 para informar suas capacidades.
(10) T2 reconhece as capacidades de T1 pelo envio de uma mensagem H.245 TerminalCapabilitySetAck.
(11) T2 informa suas capacidades para T1 pelo envio de uma mensagem H.245 TerminalCapabilitySet.
(12) T1 reconhece as capacidades de T2 pelo envio de uma mensagem H. 245 TerminalCapabilitySetAck
(13) T1 abre um canal de mídia com T2 pelo envio de uma mensagem H.245 openLogicalChannel. O endereço de transporte do canal RTCP é incluído nesta mensagem.
(14) T2 reconhece o estabelecimento do canal lógico unidirecional de T1 para T2 pelo envio da mensagem H.245 openLogicalChannelAck. Incluído nesta mensagem está o endereço de transporte RTP alocado pelo T2 para ser usado pelo T1 para envio de fluxos de mídia RTP e o endereço RTCP recebido do T1 anteriormente.
(15) Então, T2 abre um canal de mídia com T1 pelo envio de uma mensagem H.245 openLogicalChannel. O endereço de transporte do canal RTCP é incluído na mensagem.
(16) T1 reconhece o estabelecimento do canal lógico unidirecional de T2 para T1 pelo envio da mensagem H.245 openLogicalChannelAck. Incluído nesta mensagem está o endereço de transporte RTP alocado pelo T1 para ser usado pelo T2 para envio de fluxos de mídia RTP e o endereço RTCP recebido do T2 anteriormente. Agora a comunicação bidirecional de fluxos de mídia está estabelecida entre T1 e T2.
A figura abaixo ilustra o fluxo de mídia H323 e o fluxo de controle de mídia.
(17) T1 envia o fluxo de mídia encapsulado em pacote RTP para T2. (18) T2 envia o fluxo de mídia encapsulado em pacote RTP para T1. (19) T1 envia mensagens RTCP para T2.
(20) T2 envia mensagens RTCP para T1.
A liberação da chamada H.323 e apresentada na figura abaixo.
(21) T2 inicia a liberação da chamada pelo envio de uma mensagem H.245 EndSessionCommand para T1.
(22) T1 libera a chamada e confirma a liberação pelo envio da mensagem H.245 EndSessionCommand para T2.
(23) T2 completa a liberação da chamada pelo envio da mensagem H.225 release complete para T1.
(24) T1 e T2 desligam-se do gatekeeper pelo envio de uma mensagem RAS DRQ para o gatekeeper.
(25) O gatekeeper libera T1 e T2 e confirma pelo envio das mensagens DCF para T1 e T2.
5 – Considerações Finais
VoIP ainda é novo e inicia agora a ser amplamente implementado. Antes de começar a implementar VoIP, necessita-se construir uma infraestrutura de rede que suporte a VoIP, mantendo em mente as seguintes considerações.
QoS. Uma chamada de um telefone tradicional depende da ligação do circuito que a PSTN fornece com alto QoS. Um rede IP, contudo, é "connectionless" e por defeito, não fornece nem QoS nem o mesmo nível de performance e confiabilidade que a PSTN. Comunicações de Voz entre duas partes ao longo de uma rede IP envolvem muitas vezes muitas saltos na rede e aparelhos, tais como gateway H.323 e routers IP. Um delay de um só sentido end-to-end de mais de 150 milisegundos (ms) é geralmente muito longo. Para alcançar boas performances e confiabilidade para aplicações VoIP, desenvolva o QoS na sua rede antes de desenvolver a VoIP. O QoS permite priorizar o tráfego da rede e garantia de entrega de dados a tempo para aplicações sensíveis ao tempo (ex., aplicações VoIP).
Firewalls. Quando o desenvolvimento da VoIP inclui firewalls (ex., uma aplicação VoIP entre a sua intranet e a Internet), precisa de utilizar firewalls que suportem VoIP (ex., suportar H.323 se a aplicação for uma aplicação H.323). Uma aplicação H.323 negocia muitas vezes dinamicamente portas TCP e UDP para utilizar durante o estabelecimento de uma chamada.
NAT. Muitas empresas utilizam o Network Address Translation (NAT) para mapear endereços IP públicos e privados e manter o endereço IP da intranet da sua empresa da Internet. Uma aplicação H.323 pode falhar quando passar ao longo do NAT porque a aplicação pode repetir o endereço IP destinatário nos seus payloads. Se a sua NAT não está prevenido contra H.323, não pode converter o endereço no payload da aplicação quando converter o endereço no cabeçalho do pacote IP.
DHCP. Para trabalhar numa rede IP, um telefone IP precisa de um endereço IP. Um telefone IP pode utilizar DHCP para pedir um endereço dinâmico do seu servidor DHCP, mas para configurar um telefone IP, tem de adicionar várias vezes ao seu servidor DHCP a opção de um cliente DHCP que inclui parâmetros especiais para suportar VoIP. Examine o seu servidor DHCP para ver qual deles permite-lhe definir opções de cliente. O Windows 2000 e o Windows NT servidores DHCP suportam opções de cliente.
