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 – 24210-040 – 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

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.
 - 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.9311) 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).
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.

2.2.2 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
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 Indica uma que uma requisição de estabelecimento de chamada
Proceeding 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.
Alerting Ponto final de destino está sendo alertado (telefone tocando). É
enviada pelo ponto final de destino.
Connect 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.
Release Indica a liberação de uma chamada. Após a liberação, os
Complete identificadores da chamada podem ser reutilizados. É enviada por
um ponto final.
Status Resposta a uma mensagem de sinalização desconhecida ou a
uma mensagem de Status Inquiry. Fornece informações do status da
chamada.
Status Requisita informação da chamada. Pode ser enviada por um
Inquiry ponto final ou GK.
Facility Indica que o roteamento de uma chamada deve ser direto ou por
meio de um GK.

2.2.3 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
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 100.000 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
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.
 • 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 10646 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

SIP messages
Request Response

Client Server Server Client

Request=Request-Line Response=Status-Line
*(general-header *(general-header
|request-header |response-header
|entity-header) |entity-header)
CRFL CRFL
[message-body] [message-body]
 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.

Tabela 2 – Requisições SIP

Mensagem SIP Descrição
INVITE Convida um usuário a participar de uma chamada
ACK Usado para facilitar a troca confiável de mensagens INVITEs
OPTIONS Solicita informações sobre as funcionalidades do servidor
BYE Termina uma conexão entre usuários ou rejeita uma chamada
CANCEL Termina uma requisição, ou procura, por um usuário
REGISTER Registra a localização atual de um usuário
INFO 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.
 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-mail 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 e-mail, as SIP URI’s podem ser colocados em web pages ou
mensagens de e-mails. 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 e-mail. Isso possibilita que as pessoas reutilizem seus endereços de e-mail
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: 2131141001@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: 2131141001@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.
 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.
 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”, 2006. – Acme Packet
[2] H. Schulzrinne and J. Rosenberg, “Signaling for Internet Telephony”,Feb. 1998.
[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 134-141.
[6] IETF RFC 2543, “SIP: Session Initiation Protocol”, March 1999.
[7] IETF RFC 3261, “SIP: Session Initiation Protocol”, June 2002.
[8] SOUZA, I., “Voice over IP”, UFBA, Salvador, 2005.
[9] BERNAL FILHO, H., “Tutoriais sobre banda larga e VoIP”, Telefonia IP, 2003.
[10] PINHEIRO, C.D.B., “Especificação H.323”, UFPR, Dez. 2000.
[11] H.323 Forum. http://www.h323forum.org, 2006.