H.323 E SIP - COMPARATIVO

Transcrição

1 H.323 E SIP - COMPARATIVO Jean Seidi Ikuta Escola de Engenharia Universidade Federal Fluminense Rua Passo da Pátria, 156 São Domingos Niterói RJ Brasil jeanseidi@yahoo.com.br Abstract. This paper presents a brief description about H323 stack protocols and SIP protocol that are used in NGN (Next Generations Network), where it discusses a comparison between them and presents their differences, advantages and disadvantages. Keywords: H323, SIP Resumo. O presente trabalho apresenta uma breve descrição dos protocolos H323 e SIP utilizados na NGN (Next Generations Network), onde é realizado um quadro comparativo entre eles apresentando suas diferenças, vantagens e desvantagens. Palavra-chave: H323, SIP. 1 Introdução Nos últimos anos, o mercado de telecomunicações mundial tem passado por muitos desafios como manter a base de assinantes, aumentar a receita e reduzir os custos frente a crescente concorrência. Foi ficando cada vez mais claro que o pré-requisito para se chegar a idéia de informação e comunicação a qualquer hora, em qualquer lugar e em qualquer forma é a convergência das atuais redes, cada uma empregando diferentes tecnologias de transporte e controle, em uma única rede multiserviços baseada em pacotes, oferecendo serviços com diferentes qualidades e custos em uma plataforma de serviços aberta. NGN (Next Generations Network) pode ser entendida como uma rede baseada em pacotes onde a comutação por pacotes e elementos de transporte (roteadores, switches e gateways) é lógica e fisicamente separada do controle inteligente de serviços/chamadas. Esse controle inteligente é usado para suportar todos os tipos de serviços baseados em rede de pacotes, incluindo serviços básicos de voz (telefone), dados, vídeo, multimídia, e gerenciamento de aplicações, que pode ser pensado como mais um tipo de serviço que a NGN irá suportar [J. C. Crimi]. Este artigo trata dos padrões e protocolos utilizados na NGN, onde é realizado um quadro comparativo entre H.323 e SIP (Session Initiation Protocol). Na seção 2 é abordada uma visão geral sobre a pilha de protocolos que compõem o H.323. Na seção 3, de maneira análoga, é abordada uma visão geral do protocolo SIP. Um quadro comparativo entre o SIP e o H.323 é apresentado na seção 4 e a seção 5 apresenta as conclusões do trabalho. 2 Conceitos básicos do H.323

2 O padrão H.323 é parte da família de recomendações ITU-T (International Telecommunication Union - Telecommunication Standardization Sector) H.32x, que pertence à série H da ITU-T, e que trata de "Sistemas Audiovisuais e Multimídia". A recomendação H.323 tem o objetivo de especificar sistemas de comunicação multimídia em redes baseadas em pacotes. Além disso, estabelece padrões para codificação e decodificação de fluxos de dados de áudio e vídeo. 2.1 Arquitetura H.323 O padrão H.323 especifica quatro tipos de componentes, que interligados, possibilitam a comunicação multimídia. A figura 1 apresenta a arquitetura H.323. Figura 1 - Arquitetura H.323 Uma rede H.323 típica é composta por zonas ou domínios interconectados através de uma comunicação WAN (Wide Area Network). A funcionalidade de cada componente é descrita abaixo: Um Terminal (TE) H.323 é um componente da rede que provê comunicação em tempo real com outro TE H.323, Gateway (GW) ou Multipoint Control Unit (MCU). A comunicação consiste de controle, indicações, audio, vídeo, e ou dados entre os dois pontos finais (endpoints). Um terminal pode estabelecer uma chamada diretamente com outro terminal ou através da ajuda de um Gatekeeper (GK). O Gatekeeper (GK) é uma entidade H.323 na rede que provê tradução de endereços e controla o acesso (autorização e autenticação) à rede dos terminais H.323, GWs, e MCUs. Os GKs podem comunicar-se entre si para coordenar seus serviços de controle. O GK também provê serviços para os terminais, GWs e MCUs como gerenciamento de banda, localização de GWs e billing. A função do GK é opcional em sistemas H.323. Ele é logicamente separado das outras entidades H.323, mas pode coexistir fisicamente com terminais, GWs ou MCUs. A presença dele no sistema H.323 provê as seguintes funções: - Tradução de endereços: O GK traduz endereços fictícios (ex: números E164 de telefone convencional) para endereços de transporte (endereço IP e porta) usando a tabela de tradução que é atualizada através das mensagens de registro e outros modos. - Controle de admissão: O GK autoriza o acesso à rede usando mensagens H.225. Critérios de admissão incluem autorização de chamada, largura de banda, e outras políticas. - Controle de banda: O GK controla quanto de banda cada terminal pode usar.

3 - Gerência de zonas: Uma vez registrado em um GK, um TE não pode se registrar em outro GK, ou seja, um TE pode se registrar em apenas um GK por vez. O GK provê as funções descritas acima para os TEs e GWs registrados nele. Um Gateway (GW) H.323 é um componente da rede que provê comunicação em tempo real entre terminais H.323 e terminais de outras redes como PSTN, PLMN, etc. O Multipoint Control Unit (MCU) é um componente da rede que provê a funcionalidade de três ou mais terminais e GWs participarem de uma conferência mutiponto. 2.2 Sinalização e Controle em H.323 O H.323 é uma suíte completa e integrada de protocolos que definem cada um dos componentes descritos acima. Alguns dos protocolos são: H.225 para controle de registro, admissão e status (Registration, admission and status - RAS). H.225 (derivado do Q ) para sinalização da chamada, como estabelecimento e término de chamadas. H.245 para troca de informações sobre as funcionalidades do terminal e criação de canais de mídia. RTP/RTCP para sequenciamento de pacotes de audio e vídeo. G.711, uma especificação de codec. T.120 para conferência de dados. Figura 2 Protocolos em H.323 Basicamente, a sinalização no H.323 é composta de três funções (através dos protocolos H.225 e H.245). 1 Recomendação ITU-T que especifica os procedimentos de estabelecimento, manutenção e término de conexões de rede dentro da interface de usuário ISDN (Integrated Services Digital Network).

4 2.2.1 Canal de Registro, Admissão e Status (RAS) O canal RAS transporta mensagens usadas no processo de registro do TE no GK em que associa um endereço fictício (ex: número E.164 de telefone) a um endereço IP e porta para ser utilizado na sinalização da chamada. O canal RAS é também usado para transmissão de admissões a fim de estabelecer ou receber chamadas, descoberta de GKs, controle de banda, informações de status (através do envio de mensagens keep-alive), e localização de terminais (ou pontos finais). O H.225, usado no canal RAS, recomenda time-outs e contadores para as mensagens RAS, já que as mesmas são transmitidas em um canal não confiável UDP. Suas funções principais são: Descoberta de gatekeepers: Permite ao ponto final identificar em qual GK se registrar. O processo pode ser manual ou automático. Registro: Permite a pontos finais e MCUs se juntarem a uma zona. Os procedimentos de registro incluíram as seguintes mensagens: Localização de pontos finais: Permite a pontos finais e (principalmente) GKs obter informações sobre destinatários. Admissão: autoriza o acesso a uma zona H.323. Informação de status: O GK pode usar o canal RAS para obter o status de um ponto final. Controle de banda: embora a banda de uma chamada seja negociada na admissão, pode ser modificada na chamada Canal de Sinalização de Chamada O canal de sinalização de chamada carrega mensagens H.225 de controle usando conexão TCP, fazendo com que este seja um canal confiável. Em redes sem GKs, um terminal envia mensagens de sinalização diretamente para outro terminal usando endereços de transporte (endereços IP) para sinalização de chamada. Se a rede possuir um GK, o terminal chamador envia a mensagem de admissão inicial para o GK usando o endereço de transporte do canal RAS. Na troca inicial de mensagens de admissão, o GK diz ao ponto final originador se ele deve enviar as mensagens de sinalização diretamente para o outro ponto final ou se deve rotear as mensagens através dele. As mensagens de sinalização de chamada podem ser roteadas das duas formas. Tanto o H.225 quanto o H.245 usam conexões TCP para estabelecer uma conexão confiável entre pontos finais. No caso de sinalização de chamada roteada pelo GK, as conexões TCP são mantidas até o final da chamada. Embora normalmente confiável, a falha de uma conexão TCP pode resultar na terminação da chamada, mesmo se a conexão TCP não estiver em uso naquele momento. Por exemplo, suponha que uma sinalização de chamada roteada pelo GK seja usada, e que a conexão TCP entre o ponto final e o GK seja quebrada devido a um time-out ou falha na troca de mensagens keep alive durante uma falha na conexão ou roteamento. As chamadas podem cair mesmo se os fluxos RTP de áudio não forem afetados pelo evento na rede que causou a conexão

5 TCP entre o ponto final e o GK falhar. A tabela 1 lista as mensagens usadas na sinalização de chamada. Tabela 1 Mensagens utilizadas na sinalização de chamadas Mensagem Descrição Setup Indica que um ponto final deseja iniciar uma conexão com outro ponto final. Call Proceeding Alerting Connect Release Complete Status Status Inquiry Facility Indica uma que uma requisição de estabelecimento de chamada está sendo iniciada. Nenhuma informação adicional relativa ao estabelecimento da chamada será aceita após o envio desta mensagem. É enviada pelo ponto final de destino. Ponto final de destino está sendo alertado (telefone tocando). É enviada pelo ponto final de destino. Indica que a chamada sendo processada foi aceita pelo ponto final de destino. É enviada pelo ponto final que originou a chamada. Indica a porta TCP a ser usada para o estabelecimento do canal de controle H.245. Indica a liberação de uma chamada. Após a liberação, os identificadores da chamada podem ser reutilizados. É enviada por um ponto final. Resposta a uma mensagem de sinalização desconhecida ou a uma mensagem de Status Inquiry. Fornece informações do status da chamada. Requisita informação da chamada. Pode ser enviada por um ponto final ou GK. Indica que o roteamento de uma chamada deve ser direto ou por meio de um GK Canal de Controle de Funções H.245 O H.245 carrega mensagens de controle que governam a operação entre entidades H.323. A principal função é a troca de informações sobre capacidades (ou funcionalidades), como os codecs de áudio/vídeo suportados. Uma vez que a sinalização e a codificação ocorrem, o Real-time Transport Protocol (RTP) e o Real-time Control Protocol (RTCP) são utilizados para transportar os pacotes de áudio e/ou vídeo. Os fluxos de áudio/vídeo são divididos em pacotes de acordo com o formato pré-definido. Os serviços providos pelo RTP incluem identificação do tipo de dados, seqüênciamento, marcação de tempo (timestamping) e monitoração da entrega. As aplicações tipicamente rodam RTP em cima de UDP (User Datagram Protocol). O Real-time Control Protocol (RTCP) baseia-se na transmissão periódica de pacotes de controle para todos os participantes da sessão. O RTCP executa as seguintes funções de feedback da qualidade da distribuição dos dados e controla a taxa de modo

6 que o RTP possa ser escalável até um grande número de participantes. Além disso, transporta uma quantidade mínima de informação de controle de sessão. 3 Conceitos básicos do SIP SIP (Session Initiation Protocol) foi desenvolvido para estabelecer, modificar e terminar qualquer tipo de sessão. As aplicações SIP têm focado em sessões interativas multimídia, como chamadas através da Internet ou conferências multimídia. A estrutura da sua mensagem é baseada no HTTP e SMTP (protocolos baseados em texto), a fim de criar um protocolo simples, flexível e escalável. As especificações do H.323, por exemplo, possuem mais de 700 páginas e seu desenvolvimento em C++ possuem cerca de linhas de código, o que o tornam extremamente complexo. Foi padronizado pelo IETF com a RFC2543 inicialmente. O trabalho inicial do SIP recebeu grande atenção das companhias de tecnologia que estavam prontas para lançar seus produtos baseados em SIP, fato que impulsionou a sua difusão e seu uso. A RFC2543 foi substituída pelo novo conjunto de especificações baseados na RFC3261, devido ao rápido desenvolvimento e extensão às funções do SIP. 3.1 Visão Geral O SIP é um protocolo de controle da camada de aplicação que pode estabelecer, modificar e terminar sessões multimídia como ligações telefônicas através da Internet. Foi desenvolvido para que sinalização fosse simples, atendendo somente aos requisitos básicos (criar, modificar e terminar) de um protocolo de sinalização de chamadas. Logo, as chamadas podem ser estabelecidas de maneira mais rápida do que no H.323. O rápido estabelecimento de chamadas é crucial para uma alta qualidade de serviço (QoS). Além disso, um grande número de parâmetros usados na negociação e estabelecimento de fluxos de mídia entre participantes de uma chamada é encapsulado no corpo da mensagem do SIP através do SDP (Session Description Protocol), o que aumenta a velocidade no estabelecimento da chamada. [H. Schulzrinne and J. Rosenberg] SIP foi concebido com base em texto. Sua estrutura de mensagem tem facilidade de extensão a novas aplicações do que protocolos equivalentes, como o H.323 que utiliza o padrão de codificação ASN.1 em vez de texto. Desta maneira, facilita a implementação em linguagens de programação orientadas a objetos como Java e Perl, possibilitando fácil depuração de problemas e fazendo do SIP um protocolo simples, flexível e extensível. Os caminhos entre sinalização e mídia são independentes. A sinalização e mídia podem passar por diferentes rotas através de conjuntos independentes de equipamentos em diferentes redes. O SIP utiliza UDP ao invés de TCP. O estabelecimento de conexões TCP e suas rotinas de confirmações introduzem atrasos e devem ser evitados em transmissões de

7 voz. Adotando o UDP, entretanto, os tempos das mensagens e suas retransmissões podem ser controlados pela camada de aplicação. Existe um mecanismo de procura paralela, o que possibilita que vários equipamentos sejam associados a um único endereço com o intuito de que todos ou uma seleção desses equipamentos sejam contatados simultaneamente ou sequencialmente. Quem recebe a chamada é o primeiro equipamento que atender. Existem cinco etapas para estabelecimento e término de uma chamada dentre as quais são mencionados: Localização do usuário Descobrir a localização do usuário. Disponibilidade do usuário Verificar disponibilidade do usuário para chamadas telefônicas. Capacidades do usuário Negociação e determinação dos formatos de mídia a serem utilizados entre o usuário chamador e usuário chamado. Estabelecimento da sessão O diálogo é estabelecido e os fluxos de mídia são transportados. Controle da sessão, incluindo transferência e término de sessões, modificações de parâmetros da sessão e adição de serviços. 3.2 Arquitetura da Rede SIP SIP é baseado no modelo cliente-servidor, onde um cliente é qualquer elemento de rede, como um PC com um microfone ou um SIP phone, que envia requisições SIP (SIP requests) e recebe respostas SIP (SIP responses) e o servidor é um elemento de rede que recebe requisições e envia respostas, que podem aceitar, rejeitar ou redirecionar a requisição. Existem quatro tipos diferentes de servidores: proxies, user agent servers (UAS), redirect servers e registrars [RFC 3261]: Proxy: Servidores proxies são como roteadores da camada de aplicação, responsáveis por receber uma requisição, determinar para onde enviá-la baseando-se no conhecimento da localização do usuário, e então enviá-la. Para outras entidades, para que a mensagem vem do proxy e não de alguma entidade escondida atrás do proxy. Eles podem adicionar parâmetros às requisições e podem rejeitar requisições, mas não iniciam requisições ou respondem positivamente a qualquer requisição que eles recebem. As mensagens passam pelos proxies sem qualquer modificação. Isso significa que muitas novas funcionalidades podem ser implementadas na rede através do upgrade de user agents, sem qualquer modificação aos proxies. UAS: O user agent server é uma entidade lógica que gera respostas a uma requisição SIP e contacta o usuário. Na realidade, um terminal SIP (como um SIP phone) funcionará como ambos user agent client (UAC), gerando requisições, e user agent server (UAS), respondendo às requisições, provendo uma comunicação peer-to-peer.

8 Redirect server: Um redirect server é um servidor que recebe requisições SIP, localiza o endereço de destino em um conjunto de um ou mais endereços, e retorna a informação de roteamento para o originador da requisição. O originador da requisição pode então enviar uma nova requisição para o(s) endereço(s) retornado(s) pelo redirect server. O redirect server não gera requisições, apenas responde a uma requisição. Registrar: O registrar funciona como o elemento principal do serviço de localização de usuários em um domínio, consultando e adicionando mapeamentos entre usuários e endereços IP baseados nas mensagens REGISTER. Isso possibilita que um usuário seja contactado mesmo ele se registre em outro domínio que não seja o seu de origem. Os servidores proxies, que são responsáveis em enviar a requisição para o local atual onde o usuário chamado se encontra, consultam esse serviço de localização. 3.3 Mensagem SIP Conforme mencionado anteriormente, o SIP é baseado em texto (utiliza o conjunto de caracteres ISO com codificação UTF-8 8 bit unicode transformation format) e usa uma sintaxe similar ao HTTP. Uma mensagem SIP, que pode ser uma requisição de um cliente para um servidor ou uma resposta de um servidor para um cliente, é a unidade básica da comunicação usando SIP. A mensagem contém uma sequência estruturada de octetos formando uma sintaxe definida. Ambas as mensagens de requisição e resposta possuem uma linha de início (start-line), um ou mais cabeçalhos (headers), uma linha vazia (carriage-return line feed CRLF) indicando o fim dos cabeçalhos, e um corpo de mensagem (message body) opcional. Uma mensagem típica parecerá com a mostrada a seguir: Generic-message = start-line *message-header CRLF [message-body] Start-line = Request-Line Status-Line Request SIP messages Response Client Server Server Client Request=Request-Line *(general-header request-header entity-header) CRFL [message-body] Response=Status-Line *(general-header response-header entity-header) CRFL [message-body]

9 Figura 3 - mensagem SIP A RFC2543 define seis métodos que podem ser usados em requisições: INVITE, ACK, OPTIONS, BYE, CANCEL e REGISTER. Como não havia um mecanismo para carregar controle de informações durante uma sessão, o IETF adicionou o método INFO para resolver esse problema. A tabela 2 descreve resumidamente a função de cada um dos métodos. Mensagem SIP INVITE ACK OPTIONS BYE CANCEL REGISTER INFO Tabela 2 Requisições SIP Descrição Convida um usuário a participar de uma chamada Usado para facilitar a troca confiável de mensagens INVITEs Solicita informações sobre as funcionalidades do servidor Termina uma conexão entre usuários ou rejeita uma chamada Termina uma requisição, ou procura, por um usuário Registra a localização atual de um usuário Usado para troca de sinalização durante a sessão A mensagem de resposta contém um código de status (três números) indicando a consequência da tentativa de entender e satisfazer uma requisição. A tabela 3 indica os possíveis códigos, assim como suas descrições. Tabela 3 Códigos de resposta Classe Descrição Exemplo 1xx Informativo : requisição recebida, continuando o processo de requisição 100 Trying, 180 Ringing 2xx Bem sucedido : a ação foi recebida com sucesso, entendida e aceita 200 OK 3xx Redirecionado : uma ação mais adiante precisa ser tomada para que a requisição 302 Moved Temporarily possa ser completada 4xx Erro do cliente : a requisição contém sintaxe falha ou não pôde ser executada pelo 404 Not Found servidor 5xx Erro do servidor : o servidor falhou em executar uma requisição aparentemente 501 Not Implemented válida 6xx Falha global : a requisição não pôde ser executada pelo servidor 603 Decline Os cabeçalhos acompanham as mensagens a fim de prover mais informação e garantir que as mensagens sejam tratadas corretamente. O corpo da mensagem é responsável pela descrição da sessão a ser estabelecida. O tipo de mídia e codec, as taxas de amostragem fazem parte da negociação entre usuário chamador e usuário chamado. O SDP (Session Description Protocol) é utilizado por padrão para esse fim. O SDP simplesmente provê uma forma de descrever a informação contida em uma sessão, incluindo parâmetros da sessão e parâmetros de mídia. O SDP precisa ser utilizado em conjunto com outros protocolos, já que não provê um meio de transportar ou informar aos potenciais participantes de uma sessão. Como o SIP é independente das características da sessão, ele carrega a informação do SDP em seu corpo da mensagem.

10 Para estabelecer uma sessão de áudio, o usuário chamador precisa conhecer o endereço do(s) usuário(s) chamado(s). No SIP, esses endereços são similares a endereços de e são conhecidos como SIP URI (Uniform Resource Identifier). A URI é um ponteiro para um recurso que gera diferentes respostas em diferentes horas, dependendo da entrada. A URI não depende da localização do recurso e geralmente consiste de três partes: o protocolo para comunicação com o servidor (ex: SIP), o nome do servidor (ex: host.com) e o nome do recurso. A URL é a forma mais comum de URI. Como os endereços de , as SIP URI s podem ser colocados em web pages ou mensagens de s. Elas contêm informação suficiente para iniciar e manter sessões para comunicação com um usuário. SIP URI s usam o formato user@host como um endereço de . Isso possibilita que as pessoas reutilizem seus endereços de como seus endereços SIP, evitando a necessidade de se ter um outro endereço para fins de comunicação. Para interconexão com a PSTN, o SIP possibilita que a parte do endereço destinado ao nome ou apelido do usuário seja um número de telefone. Assim, podemos ter um endereço SIP do tipo: sip: @companhiatelefonica.com Em uma dada rede, este endereço SIP pode ser usado para rotear a mídia para um Media Gateway (da companhiatelefonica.com). Para indicar que a chamada é para um número de telefone, a URI pode ser complementada com o parâmetro user=phone. Nesse caso, a URI teria o seguinte formato: sip: @companhiatelefonica.com; user=phone 4 Quadro comparativo entre H.323 e SIP H.323 e SIP foram desenvolvidos para controle e sinalização de chamadas em arquiteturas de comunicação distribuídas. O H.323 é baseado em protocolos do ITU-T já existentes e tem uma abordagem voltada aos equipamentos terminais. O SIP é similar ao HTTP e tem uma abordagem voltada aos usuários e serviços integrados na Internet. Em termos de complexidade, a implementação do H.323 é maior em relação ao SIP. A documentação do H.323 tem 736 páginas contra apenas 128 do SIP o que leva o desenvolvedor a dedicar muito tempo apenas para o entendimento do funcionamento do H.323. O SIP trabalha com apenas 37 tipos de cabeçalhos enquanto que o H.323 tem centenas. O H.323 trabalha com vários protocolos sem uma separação clara, ou seja, esses protocolos são usados por vários serviços. Já no SIP, em uma mesma requisição estão todas as informações necessárias. Em se tratando de expansão funcional, temos que devido à estrutura textual do SIP, novas características são incluídas de forma fácil e compatível com versões anteriores e novos parâmetros podem ser colocados em qualquer parte de mensagem. No H.323 existem campos predefinidos para essas novas inclusões. Se um novo codec é registrado em um órgão competente, é possível ser suportado pelo SIP, enquanto o H.323 há uma dificuldade na inclusão de novos codecs porque eles devem ser padronizados pelo ITU-T. No SIP, o Proxy descreve os tipos de mídia e endereços de transporte da mídia, enquanto no H.323 temos diversos subprotocolos (H.245, H.225, etc); no SIP temos servidores com diferentes comportamentos (registrador, proxy e redirecionador), enquanto o H.323 conta com um servidor único Gatekeeper.

11 Quanto à escalabilidade, os servidores ou gateways SIP podem trabalhar nos modos stateful ou stateless, sendo que no segundo caso os servidores recebem e encaminham as requisições não mantendo nenhum tipo de informação, pois as mensagens possuem informações suficientes para garantir que a mensagem seja enviada corretamente. O H.323 é stateful, ou seja, ele mantém todo o controle do estado da chamada durante toda a duração, em um ambiente onde pode haver muitas chamadas simultaneamente implicando em problemas de desempenho. O fato de o SIP usar mensagens de texto, utilizar apenas um pedido para enviar toda a informação necessária para o estabelecimento de uma chamada e ser baseado em UDP, torna-o um protocolo com muitas potencialidades para ser usado na telefonia IP. Contudo, neste momento o H.323 tem uma vantagem de já ter muitos sistemas implementados, o que obrigará o SIP a fornecer mecanismos de interoperabilidade. Quanto à arquitetura, o H.323 tem os seguintes componentes: terminal, gateway, gatekeeper e MCU; o SIP tem UA e Servers. Os protocolos no H.323 são H.245, RAS/ Q.931, H.225, enquanto no SIP, o próprio SIP e SDP [SOUZA, I]. Em se tratando dos aspectos de segurança, o H.323 define seus mecanismos de segurança e negociação de facilidades via H.235 e também pode utilizar SSL. Autenticação e encriptação no SIP são suportadas hop-by-hop via SSL/TSL, mas o SIP pode utilizar qualquer outra camada de transporte ou mecanismo de segurança similares ao HTTP, como o SSH ou S-HTTP. Chaves para encriptação de mídia são transportadas usando SDP. Interoperabilidade entre as versões e a completa compatibilidade existente no H.323 permitem que todas as implementações baseadas nas diferentes versões podem ser integradas. Já no SIP uma nova versão pode descartar um atributo antigo que não é esperado ser mais utilizado. Isto aproxima o melhor aproveitamento do tamanho do código e reduz a complexidade do protocolo, mas perde em algumas compatibilidades em diferentes versões. Em termos de Billing, mesmo havendo o modelo de chamada direta no H.323, a habilidade de bilhetar uma chamada com sucesso não é perdida porque os terminais se reportam para o gatekeeper desde o início até o final da chamada através do protocolo RAS. Já no SIP proxy, para realizar a coleta de informação de bilhetagem é necessário estar entre o caminho de sinalização durante o tempo de duração da chamada para que ele possa detectar quando a chamada completa. 5 Conclusão O uso da Internet como meio de transporte de Voz tem alguns casos de sucesso, principalmente nas chamadas de longa distância. Hoje o usuário que está fazendo uma chamada desse tipo não consegue identificar o tipo de tecnologia que está sendo usada, e mesmo qual o caminho que a sua conversa está seguindo. Entretanto, nem todas as aplicações têm o mesmo resultado. O mercado corporativo e mesmo residencial ainda tem dificuldades para usar de forma generalizada esse tipo de tecnologia. À medida que o mercado for demandando novos serviços através da Internet, a estrutura de se estabelecer preços desses serviços poderá ser aperfeiçoada de forma a definir o custo do acesso de acordo com o tipo de aplicação do usuário.

12 Esse novo formato de custo/benefício pode permitir o aperfeiçoamento da própria arquitetura da Internet, através da implantação de protocolos mais sofisticados que permitem a definição de prioridades para o transporte dos pacotes de dados de acordo com o tipo de aplicação do usuário. A força do H.323 tem sido a sua disponibilidade de sistemas/aplicações desktop e salas de videoconferência de preço acessível. O SIP é um protocolo desenvolvido pensando-se na Internet e promete grande escalabilidade e flexibilidade. Nesse novo contexto, tanto provedores como usuários terão a oportunidade de usar a Internet para as aplicações de telefonia IP (e para outras mídias) com custos um pouco superiores aos atuais. O H.323 é um protocolo muito complexo e que define especificações para comunicação em tempo real de dados para vídeo, dados e voz, enquanto o SIP foi desenvolvido de maneira mais simples e eficiente. 6 Referências bibliográficas [1] Net-Net Session Director solutions, Acme Packet [2] H. Schulzrinne and J. Rosenberg, Signaling for Internet Telephony,Feb [3] J. C. Crimi, Next Generation Network (NGN) Services Telcordia Technologies [4] P. Falcarin and C. A. Licciardi, Analysis of NGN service creation technologies. [5] H. Schulzrinne and J. Rosenberg, The Session Initiation Protocol: Internet-Centric Signaling, IEEE Communications Magazine, Oct 2000, pgs [6] IETF RFC 2543, SIP: Session Initiation Protocol, March [7] IETF RFC 3261, SIP: Session Initiation Protocol, June [8] SOUZA, I., Voice over IP, UFBA, Salvador, [9] BERNAL FILHO, H., Tutoriais sobre banda larga e VoIP, Telefonia IP, [10] PINHEIRO, C.D.B., Especificação H.323, UFPR, Dez [11] H.323 Forum