UNIVERSIDADE FEDERAL DO PARANÁ

SETOR DE CIÊNCIAS EXATAS – DEPARTAMENTO DE INFORMÁTICA

CURSO DE ESPECIALIZAÇÃO EM INFORMÁTICA
ÊNFASE EM GERÊNCIA DE REDES DE COMPUTADORES

GERSON TAKASHI WATANABE

ANÁLISE COMPARATIVA DOS PROTOCOLOS H.323 E SIP

Curitiba - PR
2008
 GERSON TAKASHI WATANABE

ANÁLISE COMPARATIVA ENTRE PROTOCOLOS H.323 E SIP

Trabalho apresentado à banca

examinadora da Universidade Federal
do Paraná, Departamento de
Informática, para obtenção do
certificado de Especialista em
Informática – Ênfase em Gerência de
Redes de Computadores. Orientador:
Prof. Dr. Luciano Silva.

Curitiba - PR
2008

2
 PARECER DE APROVAÇÃO
MONOGRAFIA DE ESPECIALIZAÇÃO EM INFORMÁTICA
ÊNFASE EM GERÊNCIA DE REDES DE COMPUTADORES
PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA/UFPR

Declaramos que o aluno GERSON TAKASHI WATANABE entregou a versão

final da sua Monografia de Especialização em Informática da Universidade Federal
do Paraná, com Ênfase em Gerência de Redes de Computadores, intitulada Análise
Comparativa Entre Protocolos H.323 e SIP.

Curitiba, 29 de maio de 2008.

NOME DO ORIENTADOR
Professor Dr. Luciano Silva
Universidade Federal do Paraná
Setor de Ciências Exatas
Departamento de Informática
Caixa Postal 19081
CEP 81531-990 - Curitiba-PR

NOME DO MEMBRO DA BANCA

Professora Dra. Olga Regina Pereira Bellon
Universidade Federal do Paraná
Setor de Ciências Exatas
Departamento de Informática
Caixa Postal 19081
CEP 81531-990 - Curitiba-PR

3
 RESUMO

O objetivo deste trabalho é apresentar uma análise comparativa entre os protocolos

de sinalização multimídia SIP (IETF) e H.323 (ITU-T). Primeiramente é realizado o
embasamento teórico de cada um dos protocolos e ao final é realizado um
comparativo das deficiências e virtudes de um em relação ao outro.

4
 ABSTRACT

The objective of this work is to make a comparison of SIP (IETF) and H.323 (ITU-
T) multimedia signaling protocols. First of all, a theoretical approach is made with
each one of the protocols and then a comparison showing the deficiencies and virtues
of each one.

5
 SUMÁRIO

1. INTRODUÇÃO .....................................................................................................12
1.1. ITU-T E IETF .........................................................................................12
1.2. OBJETIVO .............................................................................................13
1.3. ESTRUTURA DO TRABALHO ...........................................................13
2. PROTOCOLO H.323 (ITU-T)...............................................................................14
2.1. INTRODUÇÃO ......................................................................................14
2.2. ELEMENTOS DO H.323 .......................................................................14
2.2.1. Fluxos de Informação .............................................................................14
2.2.2. Terminal..................................................................................................15
2.2.2.1 Características de vídeo ..........................................................................16
2.2.2.2 Características de áudio ..........................................................................17
2.2.2.3 Canal de dados ........................................................................................18
2.2.2.4 Função de controle H.245.......................................................................19
2.2.2.5 Negociação de capabilidade....................................................................21
2.2.2.6 Sinalização de canal lógico.....................................................................22
2.2.2.7 Determinação de mestre-escravo ............................................................22
2.2.2.8 Fluxo multiplexado de transmissão sobre um canal lógico simples.......23
2.2.2.9 Sinalização RAS .....................................................................................24
2.2.2.10 Função de sinalização de chamada .........................................................24
2.2.3. Gateway ..................................................................................................25
2.2.3.1 Decomposição lógica de um gateway.....................................................26
2.2.3.2 Decomposição física de um gateway......................................................27
2.2.3.3 Trunking e Access Gateways ..................................................................28
2.2.3.4 Exemplos de Utilização de Trunking e Access Gateways ......................30
2.2.4. Gatekeeper ..............................................................................................31
2.2.5. Características de Conferência Multiponto.............................................32
2.3. SINALIZAÇÃO DE CHAMADAS .......................................................34
2.3.1. Endereçamento........................................................................................34
2.3.2. Canal RAS (Registro, Admissão e Estado) ............................................35
2.3.3. Canal de Sinalização de Chamada ..........................................................36
2.3.4. Valor de Referência de Chamada ...........................................................36
2.3.5. Identificação de Chamada.......................................................................37
2.3.6. Identificação de Conferência e Objetivo de Conferência .......................37
2.3.7. Capacidade de Chamada de Terminal ....................................................37
2.3.8. Serviços de Identificação de Chamador..................................................38
2.4. PROCEDIMENTOS DE SINALIZAÇÃO DE CHAMADAS ..............38
2.4.1. Fase A – Call Setup ................................................................................38
2.4.2. Fase B – Comunicação Inicial e Troca de Capabilidade ........................42
2.4.3. Fase C – Estabelecimento de Comunicação Áudio Visual.....................43
2.4.4. Fase D – Serviços de Chamadas .............................................................43
2.4.5. Fase E – Finalização de Chamada ..........................................................45
3. PROTOCOLO SIP (IETF).....................................................................................46
3.1. INTRODUÇÃO ......................................................................................46
3.2. ESTRUTURA.........................................................................................47
3.3. DEFINIÇÕES .........................................................................................47
3.4. MENSAGENS SIP .................................................................................50

6
3.4.1. Requisições .............................................................................................50
3.4.2. Respostas ................................................................................................51
3.5. COMPORTAMENTO GERAL DO USER AGENT ..............................51
3.5.1. Comportamento do UAC ........................................................................52
3.5.2. Comportamento do UAS ........................................................................53
3.5.3. Comportamento do UAS stateless..........................................................54
3.6. CANCELANDO UM REQUEST ...........................................................55
3.7. REGISTROS...........................................................................................55
3.8. INFORMAÇÕES DE CAPABILIDADE...............................................56
3.9. DIÁLOGOS ............................................................................................57
3.10. SESSÃO..................................................................................................58
3.11. PROXY ....................................................................................................59
3.11.1. Stateful proxy ..........................................................................................59
3.11.2. Stateless proxy ........................................................................................61
3.12. TRANSAÇÕES ......................................................................................61
3.13. TRANSPORTE.......................................................................................62
3.14. CAMPOS DE CABEÇALHO ................................................................63
3.15. CÓDIGOS DE RESPOSTA ...................................................................65
3.15.1. Respostas provisórias 1xx.......................................................................66
3.15.2. Resposta de sucesso 2xx .........................................................................66
3.15.3. Respostas de redireção 3xx.....................................................................66
3.15.4. Resposta de falha 4xx .............................................................................67
3.15.5. Resposta de falha de servidor 5xx ..........................................................69
3.15.6. Respostas de falha global 6xx.................................................................70
3.16. USO DE AUTENTICAÇÃO HTTP.......................................................70
4. ANÁLISE COMPARATIVA ENTRE H.323 E SIP .............................................72
4.1. COMPLEXIDADE.................................................................................72
4.2. EXTENSIBILIDADE E MODULARIDADE........................................73
4.3. ESCALABILIDADE ..............................................................................74
4.4. SERVIÇOS .............................................................................................75
4.5. SEGURANÇA ........................................................................................75
5. CONCLUSÃO .......................................................................................................77
6. REFERÊNCIAS BIBLIOGRÁFICAS...................................................................79

7
 LISTA DE TABELAS

Tabela 1 - Tipos de terminal para determinação mestre-escravo H.245 (fonte: ITU-T) 23

8
 LISTA DE FIGURAS

Figura 1 – Escopo da recomendação H.323 (fonte: ITU-T) ........................................... 15

Figura 2 – Exemplo de topologia com gateways (fonte: autor)...................................... 25
Figura 3 - Arquitetura funcional de um gateway decomposto logicamente (fonte:
ITU-T) ....................................................................................................... 26
Figura 4 - Decomposição de gateway SS7 (fonte: ITU-T)............................................. 28
Figura 5 - Relacionamento entre gateways H.323, SCN e H.248 (fonte: ITU-T) .......... 29
Figura 6 - Relacionamento entre H.323 e H.248 (fonte: ITU-T).................................... 29
Figura 7 - Trunking Gateways decompostos entre dois provedores de serviço (fonte:
ITU-T) ....................................................................................................... 30
Figura 8 - Access Gateway de um provedor de serviços (fonte: ITU-T)........................ 30
Figura 9 - Possíveis localizações de um MC ou MP (fonte: ITU-T).............................. 33
Figura 10 - Call setup básico sem gatekeeper (fonte: ITU-T)........................................ 39
Figura 11 - Terminais registrados no mesmo gatekeeper, com sinalização direta
(fonte: ITU-T)............................................................................................ 39
Figura 12 - Terminais registrados no mesmo gatekeeper, com sinalização roteada
(fonte: ITU-T)............................................................................................ 40
Figura 13 - Somente terminal chamador registrado, sinalização direta (fonte: ITU-T) . 40
Figura 14 - Somente terminal chamador registrado, sinalização roteada (fonte: ITU-
T) ............................................................................................................... 41
Figura 15 - Chamador registrado no gatekeeper, sinalização direta (fonte: ITU-T) ...... 41
Figura 16 - Exemplo de requisição REGISTER (fonte: IETF) ...................................... 56
Figura 17 - Exemplo de requisição OPTIONS (fonte: IETF)......................................... 56
Figura 18 - Exemplo de resposta OPTIONS (fonte: IETF) ............................................ 57
Figura 19 - Modelo de Proxy Stateful (fonte: IETF) ...................................................... 60
Figura 20 - Relacionamento de transações (fonte: IETF)............................................... 62

9
LISTA DE ABREVIATURAS E SIGLAS

ACF Admission Confirmation

ACK Acknowledge
AOR Address Of Record
APDU Application Protocol Data Unit
ARJ Admission Reject
ARQ Admission Request
ASCII American Standard Code for Information Interchange
BCF Bandwidth Change Confirmation
BNF Backus–Naur Form
BRJ Bandwidth Change Reject
BRQ Bandwidth Change Request
BRI Basic Rate Interface
CAS Channel Associated Signaling
CCITT Commité Consultatif International de Telegraphique et Telephonique
CID Conference Identifier
CIF Common Intermediate Format
CRFL Carriage-Return Line-Feed
CRV Call Reference Value
CT Client Transaction
DoS Denial Of Service
DNS Domain Name System
FAS Facility Associated Signaling
GCC Generic Conference Control
GW Gateway
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
ID Identification
IETF Internet Engineering Task Force
IMT Inter-Machine Trunk
IP Internet Protocol
IPX Internetwork Protocol Exchange
IRQ Information Request
IRR Information Request Response
ITU International Telecommunication Union
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LAN Local Area Network
MC Multipoint Controller
MCU Multipoint Control Unit
MEGACO Media Gateway Control
MGC Media Gateway Controller
MG Media Gateway
MIKEY Multimedia Internet KEYing
MIME Multipurpose Internet Mail Extensions
MMUSIC Multiparty Multimedia Session Control Working Group IETF

10
MP Multipoint Processor
NAT Network Address Translation
NFAS Non-Facility Associated Signaling
NNI Network-to-Network Interface
PABX Private Automatic Branch Exchange
PGP Pretty Good Privacy
PRI Primary Rate Interface
PSTN Public Switched Telephone Network
QCIF Quarter Common Intermediate Format
QoS Quality Of Service
QSIG Signaling Between the Q Reference points
RAS Registration, Admission, Status
RFC Request For Comments
RTCP Real Time Control Protocol
RTP Real Time Protocol
RTSP Real Time Streaming Protocol
S/MIME Secure / Multipurpose Internet Mail Extensions
SCM Selected Communications Mode
SCN Switched Circuit Network
SCTP Stream Control Transmission Protocol
SDP Session Description Protocol
S-HTTP Secure Hypertext Transfer Protocol
SIP Session Initiation Protocol
SIPS Session Initiation Protocol Secure
SPX Sequential Protocol Exchange
SRTP Secure Real Time Transport Protocol
SS7 Signaling System n. 7
SSH Secure Shell
SSL Secure Sockets Layer
ST Server Transaction
TCP Transport Control Protocol
TLS Transport Layer Security
TSAP Transport layer Service Access Point
TU Transaction User
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
URI Uniform Resource Identifier
URL Uniform Resource Locator
WWW World Wide Web

11
1. INTRODUÇÃO

O H.323 (ITU-T) e o SIP (IETF) são atualmente os dois protocolos de sinalização

mais utilizados em voz sobre IP. A rivalidade entre os dois é latente, os defensores de
cada um são radicais quando se trata de comparações e há quem defenda ambos os
protocolos. É difícil afirmar de forma definitiva qual deles é o melhor, o mais
confiável, o mais robusto ou qual será o protocolo de sinalização mais utilizado
daqui dez anos. Ou ainda se algum deles tende a se extinguir ou não.

Ambos possuem características distintas e estão sendo muito usados. Enquanto a

recomendação ITU-T é muito mais completa e, ao mesmo tempo, mais complexa, a
RFC referente ao SIP, do IETF, de certa forma simplifica a maneira de se estabelecer
uma chamada de voz sobre IP, mas acaba se tornando um tanto quanto minimalista,
indo de encontro aos princípios do H.323. A primeira versão do H.323 de 1996 se
definia como um “sistema de telefones e equipamentos visuais para redes locais que
provêem qualidade de serviço não-garantida”. Com o avanço do protocolo e a
demanda por novos serviços, esta denominação foi se alterando, chegando-se a
versão atual (2006) como “sistemas de comunicação multimídia baseadas em
pacotes” [1]. O SIP foi criado com o objetivo de ser um protocolo de Internet, com
sinalização em texto claro, baseado no conhecido protocolo HTTP (camada de
aplicação). O SIP surgiu em meados de 1996 como um internet draft do IETF, com o
primeiro RFC sendo publicado em 1999. A versão mais atual publicada é a RFC
3261 do ano de 2002.

1.1. ITU-T E IETF

O ITU-T (o último “T” faz referência ao setor de padronização da instituição) é uma

entidade internacional de origem européia, anteriormente conhecida como CCITT, de
reconhecido respaldo perante a comunidade envolvida com telecomunicações. Além
disso, é reconhecida como a agência oficial das Nações Unidas especializada em
telecomunicações [1]. Já o IETF é um consórcio de caráter internacional que surgiu
em 1986, originalmente vinculado ao governo dos Estados Unidos. Com o

12
crescimento exponencial da Internet, diversos indivíduos e instituições de outros
países se envolveram com a entidade em prol de um objetivo comum, que é o
desenvolvimento da arquitetura da Internet e sua correta operação [2], o que tornou a
entidade mais internacional do que norte-americana.

1.2. OBJETIVO

O objetivo deste trabalho é explanar de forma detalhada e objetiva as características

dos protocolos H.323 e SIP, assim como realizar uma análise comparativa entre os
dois protocolos.

1.3. ESTRUTURA DO TRABALHO

Nos capítulos dois e três o trabalho abordará as características individuais de cada

protocolo, fornecendo uma visão geral de funcionamento e detalhes de sinalização.
No capítulo quatro a abordagem é comparativa, analisando-se as vantagens e
desvantagens que cada protocolo tem em relação ao outro.

13
2. PROTOCOLO H.323 (ITU-T)

2.1. INTRODUÇÃO

O padrão H.323 é parte da família de recomendações que pertence à série H da ITU-

T, que trata de sistemas audiovisuais e multimídia. Esta recomendação tem por
objetivo especificar sistemas de comunicação multimídia em redes baseadas em
pacotes e que não provêem qualidade de serviço garantida, estabelecendo padrões
para codificação e decodificação de fluxos de dados de áudio e vídeo, garantindo que
produtos baseados no padrão H.323 de um fabricante sejam operacionais quando se
comunicando com produtos H.323 de outros fabricantes [3].

A recomendação H.323 especifica o uso de áudio, vídeo e dados em comunicações

multimídia, sendo que apenas o suporte à mídia de áudio é obrigatório. Mesmo sendo
somente o áudio obrigatório, cada mídia (áudio, vídeo e/ou dados), quando utilizada,
deve seguir as especificações do padrão. Pode-se ter uma variedade de formas de
comunicação, envolvendo áudio apenas (telefonia IP), áudio e vídeo
(videoconferência), áudio e dados e, por fim, áudio, vídeo e dados.

As informações contidas neste capítulo sobre H.323, quando não citado outro autor,
são baseadas em [1].

2.2. ELEMENTOS DO H.323

2.2.1. Fluxos de Informação

Os componentes de um terminal H.323 se comunicam através de fluxos de

informação, que podem ser classificados como:

• Áudio: contêm uma fala digitalizada e codificada, acompanhada de uma

sinalização de controle de áudio.

14
 • Vídeo: contêm vídeo animado digitalizado e codificado, sendo transmitido a
uma taxa não maior que a selecionada, resultado da troca de informações de
capabilidade.
• Dados: inclui figuras, fax, documentos, arquivos diversos de computador e
outros fluxos de dados.
• Sinais de controle de comunicação: passam dados de controle entre elementos
“remotos” e são usados para negociação de capabilidade, abertura e
fechamento de canais lógicos, controles de modo e outras funções que fazem
parte do controle de comunicação.
• Sinais de controle de chamada: utilizados para estabelecimento, desconexão e
outras funções de controle de chamada.

2.2.2. Terminal

Figura 1 – Escopo da recomendação H.323 (fonte: ITU-T)

Um terminal é toda entidade capaz de se comunicar através do protocolo H.323 e que

se utiliza do escopo mostrado na figura 1. Todo terminal H.323 é obrigado a possuir

15
uma unidade de controle de sistema, uma camada H.225.0, uma interface de rede e
uma unidade de codec de áudio. Opcionalmente o terminal pode possuir uma unidade
de codec de vídeo e aplicações de dados de usuário.

Na interface de rede (e na rede conectada a ela é claro), é imprescindível a

disponibilidade dos seguintes serviços:

• Serviço fim a fim confiável (TCP, SPX, etc.): obrigatório para o canal de
controle H.245, canais de dados, canal de sinalização de chamada.
• Serviço fim a fim não-confiável (UDP, IPX, etc.): obrigatório para os canais
de áudio, canais de vídeo e o canal RAS.

Estes serviços poderão ser disponibilizados na forma de transmissão simplex ou

duplex, unicast ou multicast, dependendo da aplicação, das capabilidades do terminal
e da configuração da rede.

2.2.2.1 Características de vídeo

Uma vez que algum terminal possua capabilidade de vídeo (que é opcional), é
mandatório que o mesmo seja capaz de codificar e decodificar vídeo de acordo com a
recomendação H.261 QCIF, que é o codec de vídeo com taxa de 30 quadros por
segundo, sendo que cada um destes quadros possui as dimensões de 144 linhas e 176
pixels por linha. Este formato, como o próprio nome sugere, equivale a um quarto da
resolução total do formato CIF [4]. Opcionalmente, o terminal pode ter suporte a
outros modos do H.261 (CIF, por exemplo) e também outros codec’s como H.263 ou
H.264, que possuem algoritmos aperfeiçoados e desempenho superior.

Outros codec’s de vídeo e formatos de imagem podem ser utilizados através de

negociação H.245, sendo que mais de um canal de vídeo pode ser transmitido e/ou
recebido ao mesmo tempo (por exemplo, em uma sessão de videoconferência
multiponto), quando negociado pelo canal de controle H.245. O codificador poderá
somente transmitir características de vídeo que foram estabelecidas com o

16
decodificador, durante a negociação de capabilidade. Além disso, os terminais H.323
têm a opção de operação em diferentes taxas de bit ou taxas de quadros. Por
exemplo, um terminal pode transmitir QCIF enquanto recebe CIF.

Quando um canal lógico de vídeo é aberto, o modo de operação a ser utilizado é

sinalizado do transmissor ao receptor através da mensagem H.245
“openLogicalChannel”. É no cabeçalho dentro do canal lógico de vídeo que se
encontra indicado o modo utilizado naquele instante para cada imagem, dentro da
capabilidade do decodificador.

2.2.2.2 Características de áudio

É obrigatório que um terminal H.323 possua o codec de áudio G.711 e seja capaz de
transmitir e receber nos modos A-law e µ-law. Opcionalmente outros codec's podem
ser utilizados sem problemas, uma vez que sejam sinalizados pelo canal H.245. Isso
ocorre durante a troca de capabilidade entre as entidades envolvidas (codificador e
decodificador). Similarmente à característica de vídeo, o áudio tem a possibilidade de
operação assimétrica, ou seja, um terminal pode, por exemplo, enviar áudio em
G.711 e receber em G.723, desde que codificador e decodificador tenham
capabilidade de ambos os codec's.

Pacotes de áudio devem ser entregues periodicamente a camada de transporte em um

intervalo determinado pela recomendação ITU-T do codec de áudio em uso. A
entrega de cada pacote deve ocorrer em não menos que 5ms, depois de um múltiplo
inteiro do intervalo de quadro de áudio, mensurado a partir da entrega do primeiro
quadro de áudio (audio delay jitter). Codificadores capazes de limitar seu tempo de
audio delay jitter devem sinalizá-lo utilizando-se o parâmetro H.245
“maximumDelayJitter”, da estrutura “h2250Capability” contida dentro da mensagem
“terminal capability set message”. Assim os receptores podem opcionalmente
reduzir o buffer de jitter delay.

Para definir corretamente o tamanho do buffer de jitter, os terminais H.323 devem

17
transmitir a mensagem “h2250MaximumSkewIndication” para indicar a diferença
máxima de tempo entre os sinais de áudio e vídeo, para serem entregues a rede de
transporte. Esta mensagem deverá ser enviada para cada par de canais lógicos de
áudio e vídeo associados. Esse procedimento não é necessário em conexões
exclusivas de áudio.

Em chamadas de conferência, os terminais H.323 devem ser capazes de realizar

recepção de mais de um canal de áudio, mixando todos os canais que estão sendo
recebidos ao mesmo tempo. O terminal deve usar capabilidade simultânea do H.245
para indicar quantos fluxos de áudio será capaz de decodificar ao mesmo tempo.
Essa capabilidade simultânea não pode limitar o número de fluxos de áudio que estão
sendo transmitidos em multicast em uma conferência.

2.2.2.3 Canal de dados

Um ou mais canais de dados são opcionais para um terminal, podendo ser

unidirecional ou bidirecional. A recomendação T.120 é a base padrão de
interoperabilidade entre terminais H.323 com outros tipos de terminais como H.323,
H.324, H.320 ou H.310. Esta recomendação descreve uma série de protocolos
aplicativos e de comunicação que provêem suporte para comunicação de dados
multiponto em tempo real. Aplicativos como Microsoft Netmeeting ou Lotus
Sametime se utilizam desta recomendação [5].

Uma conexão T.120 é estabelecida durante uma chamada H.323, sendo uma parte
essencial desta chamada. Depois da troca de capabilidades, um canal lógico
bidirecional deve ser aberto para a conexão T.120, através da mensagem
“openLogicalChannel”. Se o terminal que está sendo convidado, aceitar a abertura
de canal, então este enviará a mensagem “openLogicalChannelAck”. Nesta
mensagem, o terminal convidado deve incluir seu endereço de transporte, mesmo
esperando que o terminal chamador inicie a chamada. Em todos os casos, o endereço
de transporte deve estar presente no parâmetro “separateStack” e deve permanecer
válido pelo tempo da duração da conexão do canal lógico T.120.

18
Em ambas as mensagens “openLogicalChannel” e “openLogicalChannelAck”, a
alternativa “t120SetupProcedure”, da estrutura “NetworkAccessParameters” indica
à parte oposta (chamador ou recebedor) como a chamada será estabelecida. A opção
“originateCall” diz ao emissor da mensagem para iniciar a chamada. Já a opção
“waitForCall” significa que o emissor da mensagem irá receber a chamada.

No caso de conferência, que inclui áudio, vídeo e dados T.120, quando um terminal
tiver a intenção de iniciar uma, o canal de controle H.245 precisa ser estabelecido
antes que a conexão T.120 seja realizada. Isso se aplica a criação de conferência,
entrada em conferência estabelecida e convite/ações de um MC de uma conferência.
Os procedimentos de call setup devem ser utilizados para se estabelecer o MC ativo
(se existir), antes da conexão T.120.

Usando-se uma requisição GCC de entrada em conferência estabelecida, para se

estabelecer uma conexão T.120, os terminais necessitam saber o nome da
conferência T.120. Se um nome para a conferência H.323 já existe (conferenceAlias),
o mesmo nome pode ser usado como o nome de conferência T.120. Da mesma
forma, o CID H.323 poderá ser utilizado como o nome de conferência T.120
numérico. Cada octeto do CID H.323 é convertido em uma séria de três caracteres
ASCII, que representa o valor decimal do octeto.

O encerramento de uma conferência T.120 não implica o encerramento de uma

chamada H.323. Quando o fluxo de dados T.120 é encerrado, a chamada H.323
continua ativa. Mas quando o contrário ocorre, ou seja, a chamada H.323 é
encerrada, o fluxo de dados automaticamente termina também.

2.2.2.4 Função de controle H.245

A função de controle utiliza o canal H.245 para enviar mensagens de controle fim a
fim, gerenciando a operação de entidades H.323, incluindo negociação de
capabilidade, abertura e fechamento de canais lógicos, requisições de preferência de
modo, mensagens de controle de fluxo e comandos genéricos.

19
Esta sinalização pode ser estabelecida entre:

• Dois terminais;
• Um terminal e um MC;
• Um terminal e um gatekeeper

Para cada chamada H.323 que um terminal estabeleça, haverá somente um canal
lógico de controle H.245 aberto. É importante salientar que terminais, MCU’s,
gateways ou gatekeepers podem (e devem) suportar mais de uma chamada ao mesmo
tempo e, conseqüentemente, um canal de controle para cada uma destas chamadas. O
canal de controle H.245 deve ser transportando pelo canal lógico zero.

A recomendação H.245 especifica um número de entidades de protocolo que

suportam comunicação de sinalização de terminal a terminal. Uma entidade de
protocolo é especificada pela sua sintaxe (mensagens), semânticas e um conjunto de
procedimentos que especifica a troca de mensagens e a interação com o usuário. Os
terminais H.323 devem suportar as seguintes entidades de protocolo:

• Determinação de mestre/escravo.
• Negociação de capabilidade.
• Sinalização de canal lógico.
• Sinalização bidirecional de canal lógico.
• Fechamento de canal lógico de sinalização.
• Requisição de modo.
• Determinação de Round Trip Delay.
• Sinalização de loop de manutenção.

Existem quatro categorias de mensagens H.245:

• Requisição (request).
• Resposta (response).
• Comando (command).

20
 • Indicação (indication).

Mensagens de requisição e resposta são utilizadas por entidades de protocolo. As

requisições exigem uma imediata ação do receptor, que é a resposta. Mensagens de
comando exigem também uma ação do receptor, mas não precisam de resposta. Já as
mensagens de indicação são somente informativas, não requerendo nenhuma ação do
receptor.

2.2.2.5 Negociação de capabilidade

A negociação de capabilidade é a troca de informações entre terminais, quanto às

suas características de transmissão e recepção, realizada antes de uma conexão ser
estabelecida.

As capabilidades de recepção descrevem as habilidades de um terminal receber e

processar fluxos de informação. Neste caso os transmissores devem limitar o
conteúdo da informação enviada, para os padrões que o receptor indicou na
negociação de capabilidade. Se o terminal omitir informações de capabilidade de
recepção, então este terminal não é apto a receber fluxos de informação, somente
transmitir.

As capabilidades de transmissão descrevem as habilidades de um terminal para

transmitir fluxos de informação. Estas capabilidades servem para os transmissores
oferecerem aos receptores, alternativas de possíveis modos de operação, para desta
forma, o receptor requisitar o modo que ele prefere utilizar. Em caso de omissão de
capabilidade de transmissão, isso indica que o terminal não está oferecendo uma
alternativa de modos preferenciais ao receptor (mas ele poderá ainda assim transmitir
qualquer informação que esteja dentro das capabilidades do receptor).

As capabilidades de transmissão e recepção descrevem as habilidades de um terminal

para receber e transmitir fluxos de informação, quando estas capabilidades não são
independentes e são requeridas a operarem em ambas as direções.

21
2.2.2.6 Sinalização de canal lógico

Cada canal lógico carrega informação de um transmissor para um ou mais receptores

e é identificado por um número de canal lógico que é único para cada direção de
transmissão. Canais lógicos são abertos e fechados usando-se as mensagens
“openLogicaChannel” e “closeLogicalChannel”, mais os procedimentos da
recomendação H.245.

Quando um canal lógico é aberto, a mensagem “openLogicalChannel” descreve

totalmente o conteúdo do canal lógico, incluindo tipo de mídia, algoritmo em uso,
quaisquer opções e toda informação requerida pelo receptor para interpretar o
conteúdo do canal lógico. Canais lógicos podem ser fechados quando não forem mais
necessários. A abertura de canal lógico deve permanecer inativa, caso a fonte de
informação não tenha nada a enviar.

Quando o terminal iniciador envia a mensagem “openLogicalChannel” para iniciar o

processo de abertura de canal lógico, e se o canal lógico for para transporte de mídia
RTP (áudio ou vídeo), a mensagem deve incluir o parâmetro
“mediaControlChannel” contendo o endereço de transporte para o canal reverso
RTCP.

O terminal respondedor, retornando a mensagem “openLogicalChannelAck”, deve

conter o parâmetro “mediaChannel”, que contêm o endereço de transporte RTP para
o canal de mídia. A mensagem deve conter também o parâmetro
“mediaControlChannel”, que vai indicar o endereço de transporte do canal RTCP.
Tipos de mídia que não utilizam RTP/RTCP (como dados T.120), devem omitir o
parâmetro “mediaControlChannel”.

2.2.2.7 Determinação de mestre-escravo

Os procedimentos H.245 de determinação mestre-escravo são utilizados para

resolver conflitos entre dois terminais, podendo ambos estar tentando ser um MC

22
(controlador multiponto) de uma conferência ou entre dois terminais tentando abrir
um canal lógico bidirecional. Neste procedimento, dois terminais trocam números
aleatórios em uma mensagem H.245 “masterSlaveDetermination”, para determinar
quem é mestre e quem é escravo.

Os terminais devem configurar o “terminalType” com os valores dados na tabela 13

e configurar o “statusDeterminationNumber” para um número aleatório,
compreendido entre 0 e 224-1. Apenas um número aleatório pode ser adquirido pelo
terminal para cada ligação e um MC ativo em conferência deve ter valor 240 para
“terminalType”.

“terminalType” Entidade H.323

Característica Terminal Gateway Gatekeeper MCU
Entidade sem MC 50 60 - -
Entidade com MC, mas sem MP 70 80 120 160
Entidade com MC, com dados MP - 90 130 170
Entidade com MC, com dados e áudio MP - 100 140 180
Entidade com MC, com dados, áudio e vídeo MP - 110 150 190
Tabela 1 - Tipos de terminal para determinação mestre-escravo H.245 (fonte: ITU-T)

2.2.2.8 Fluxo multiplexado de transmissão sobre um canal lógico simples

Múltiplos fluxos de mídia podem ser multiplexados sobre um único canal lógico,
utilizando-se os protocolos H.222 ou H.223. Multiplexando um fluxo de mídia, um
terminal se aproveita de alguns benefícios como a utilização mais eficiente de banda,
sincronização precisa de mídia e baixo atraso em transmissões multimídia.

Existem duas maneiras de se controlar um fluxo multiplexado. Uma delas é através

de mensagens H.245 encapsuladas nos pacotes RTP. Neste caso, o terminal
primeiramente abre um canal lógico para a transmissão de mídia multiplexada, como
uma transmissão RTP qualquer. Depois de estabelecida, o controle da multiplexação
de fluxos é realizado pelas mensagens H.245 encapsuladas nos pacotes RTP.

23
A outra forma de se controlar fluxos multiplexados é através de mensagens H.245
enviadas de maneira normal, como em um fluxo não multiplexado. A diferença é que
na abertura de canal lógico de sinalização, este possuirá parâmetros relativos à mídia
multiplexada.

2.2.2.9 Sinalização RAS

A função RAS de sinalização utiliza-se de mensagens H.225.0 para realizar registro,

admissões, alteração de largura de banda, estado e procedimentos de desconexão
entre terminais e gatekeepers. O canal RAS de sinalização é independente do canal
de sinalização e do canal de controle H.245. O procedimento de abertura de canal
lógico H.245 não são utilizados para se estabelecer um canal de sinalização RAS. Em
cenários onde não há a presença de um gatekeeper, a sinalização RAS não é
utilizada. Já em cenários onde existe um gatekeeper (uma zona), o canal de
sinalização RAS é utilizado entre o terminal e um gatekeeper e é aberto
prioritariamente a outros canais de sinalização entre terminais H.323.

2.2.2.10 Função de sinalização de chamada

A função de sinalização de chamada utiliza-se de sinalização H.225.0 para

estabelecer uma conexão entre dois terminais H.323. Esta função é independente do
canal RAS e do canal de controle H.245, sendo que os procedimentos de abertura de
canal lógico não são utilizados para estabelecer o canal de sinalização de chamada.

O canal de sinalização de chamada é sempre aberto antes do estabelecimento do

canal lógico H.245 e qualquer outro canal lógico entre entidades H.323. Este canal é
aberto entre um gatekeeper e um terminal H.323 ou, quando não existir um
gatekeeper, entre dois terminais H.323.

24
2.2.3. Gateway

O princípio dos gateways é trabalhar como uma interface de tradução entre uma rede
de dados (IP, por exemplo) e uma rede de circuito comutado (sistema telefônico
convencional), provendo tradução apropriada entre formatos de transmissão
diferentes.

O gateway pode ser considerado um terminal H.323 e também um terminal da rede

de circuito comutado. Gatekeepers não precisam se preocupar se um terminal é um
gateway ou não, pois no momento do registro do gateway ou terminal simples, o tipo
de terminal é indicado, dizendo se é ou não um gateway sendo registrado em um
gatekeeper.

A função de conversão dos gateways provê a conversão necessária de formatos de

transmissão, controles, áudio, vídeo e/ou fluxo de dados entre diferentes terminais de
diferentes protocolos. De acordo com a recomendação H.323, o mínimo que o
gateway deve prover é uma função de conversão para formatos de transmissão, sinais
e procedimentos de call setup, e procedimentos e sinais de controle de comunicação.

Terminal
Terminal H.323
H.323

Gateway Gateway
(funções de (funções de
conversão) conversão)

Terminal da Terminal da
SCN SCN

Figura 2 – Exemplo de topologia com gateways (fonte: autor)

25
2.2.3.1 Decomposição lógica de um gateway

Esta seção identifica um grupo de interfaces e funções, a ser utilizado para decompor
gateways H.323. Este grupo endereça cada interface e seu protocolo resultante, mas
certas implementações de gateways devem escolher em agrupar dois ou mais
componentes funcionais dentro de um único dispositivo físico. Por esta razão,
interfaces podem prover a capabilidade de transparentemente transportar outros
protocolos.

Figura 3 - Arquitetura funcional de um gateway decomposto logicamente (fonte: ITU-T)

Na figura 3, que representa um gateway decomposto, a interface “A” representa o

protocolo de controle de dispositivo definido pelo H.248.1, que é utilizado para criar,
modificar e terminar conexões de Gateway media. A interface “B” representa os
componentes de protocolo H.225.0 e H.245 que ativam as interfaces de sinalização,
no lado IP do gateway. A interface “C” descreve a função de controle de chamada do
tipo ISDN, entre FAS SCN e a lógica de controle de gateway. Já na interface “D”,
podemos observar o protocolo que converte a sinalização NFAS SCN para o

26
controlador. Esta decomposição provê a flexibilidade de conservar pontos de código
SS7 e permite que o comutador SS7 sirva múltiplos Gateway Controllers
decompostos.

A decomposição lógica de um gateway facilita o agrupamento de todos estes

elementos dentro de dispositivos físicos, visando a implementação de todas as
interfaces para produzir um equipamento de alta escalabilidade e padronização.

2.2.3.2 Decomposição física de um gateway

Um gateway basicamente se divide em duas partes: o Media Gateway Controller

(MGC) e o Media Gateway (MG).

As funções do MGC são:

• Manipular mensagens RAS H.225.0 com um gatekeeper externo.

• Opcionalmente manipular a interface de sinalização SS7.
• Opcionalmente manipular a interface de sinalização H.323.
• Responsável pela alocação e administração de recursos de alto-nível
(canceladores de eco, por exemplo).

As funções do MG são:

• Terminação da interface de rede IP.

• Terminação da extensão de rede SCN.
• Manipular sinalização H.323 em algumas decomposições físicas.
• Manipular sinalização FAS SCN em algumas decomposições físicas.
• Responsável pela alocação e administração de recursos de baixo-nível, assim
como manipulações de hardware requeridas para comutar e processar fluxos
de mídia dentro do Media Gateway.

Na figura 4 está ilustrado um exemplo de gateway decomposto fisicamente.

27
 Figura 4 - Decomposição de gateway SS7 (fonte: ITU-T)

2.2.3.3 Trunking e Access Gateways

Os termos trunking e access gateways são utilizados tanto no H.323 como no H.248,
assim como fazem parte da terminologia utilizada em comutação por circuito, onde
são aplicadas para funções tandem e de comutador de acesso.

Na SCN, um comutador tandem ou trunking conecta redes usando um protocolo

NNI, como o SS7/ISUP ou CAS NNI. Já um comutador de acesso refere-se às
centrais comutadoras que possuem conexões de usuários, utilizando-se BRI/PRI e é
também conectado a redes maiores, via protocolo NNI. Um comutador misto possui
as duas funções.

No H.323, trunking gateways são entidades com uma verdadeira função tandem,
sendo que a transparência de protocolos convertidos é essencial, ou seja, se por uma
das interfaces o protocolo utilizado é o QSIG, este deve ser “invisível” a outro
trunking gateway, por exemplo. Esta transparência é possível devido ao tunelamento
baseado na negociação de protocolo H.225.0 e Anexo M do mesmo. A figura abaixo
exemplifica bem esta questão da transparência.

28
 Figura 5 - Relacionamento entre gateways H.323, SCN e H.248 (fonte: ITU-T)

Trunking e access gateways são termos também utilizados na recomendação H.248.

O trunking gateway é aquele que a sinalização é conectada diretamente no MGC, ou
seja, é um ISUP. Entretanto, analisando-se da perspectiva decomposta do H.323, o
termo ganha variações. Um trunking gateway é aquele que a sinalização chega no
MG e então é passada via H.248 para o MGC.

Figura 6 - Relacionamento entre H.323 e H.248 (fonte: ITU-T)

29
2.2.3.4 Exemplos de Utilização de Trunking e Access Gateways

Na figura 11 observa-se um exemplo de chamada roteada através da rede comutada

por pacotes (IP, por exemplo), entre dois provedores de serviço. A interface “A”
neste caso é utilizada para controlar os Media Gateways, a interface “X” é a
sinalização entre MGC’s (H.225) e o Media Flow é o fluxo de voz sobre uma rede
comutada por pacotes entre os dois gateways.

Figura 7 - Trunking Gateways decompostos entre dois provedores de serviço (fonte: ITU-T)

Na figura 12 é exemplificado um Access Gateway que conecta um PABX

corporativo através de um enlace CAS, aos serviços do provedor, que tem o gateway
conectado a uma rede de comutação por circuito SS7. Neste exemplo “X” é a
sinalização H.225.0 entre o Access Gateway e o gateway composto conectado ao
PABX, e “A” é a sinalização de controle do MG.

Figura 8 - Access Gateway de um provedor de serviços (fonte: ITU-T)

30
2.2.4. Gatekeeper

O gatekeeper é uma entidade (opcional) em um sistema H.323 que provê serviços de

controle de chamadas para os terminais H.323. Logicamente, o gatekeeper se
encontra separado dos terminais, mas fisicamente podem existir implementações em
que ele possa coexistir com um terminal, MCU, gateway, MC ou algum outro
dispositivo que não seja H.323.

A área (lógica) de alcance em que um gatekeeper atua e controla terminais é

chamada zona. Em uma zona é permitido existir somente um gatekeeper, embora
múltiplos dispositivos físicos possam oferecer os serviços de gatekeeper em uma
única zona. Estes múltiplos dispositivos físicos, adicionais em uma zona, são
chamados de gatekeepers alternativos. Como o próprio nome sugere, eles são
gatekeepers com função de redundância.

Os seguintes serviços são obrigatórios estarem presentes em um gatekeeper:

• Tradução de endereço: O gatekeeper deverá traduzir o endereço alias para o

endereço de transporte. Isso é realizado utilizando-se uma tabela de tradução
que é atualizada através das mensagens de registro (assunto abordado no
capítulo referente à sinalização).
• Controle de admissão: O gatekeeper deve autorizar acesso à rede utilizando-
se de mensagens H.225.0 ARQ/ACF/ARJ. A decisão de autorização se baseia
em autorização de chamada, largura de banda ou algum outro critério
definido pelo desenvolvedor.
• Controle de largura de banda: O gatekeeper deve ter suporte a mensagens
BRQ/BRJ/BCF, que é baseado na administração de largura de banda.
• Administração de zona: O gatekeeper deve prover as funções acima citadas
para terminais, MCU’s e gateways que se registraram nele.

Existem também outros serviços que podem ser implementados em gatekeepers, mas
não obrigatórios estarem presentes de acordo com a recomendação H.323:

31
 • Sinalização de Controle de Chamada: O gatekeeper pode escolher a
completar a sinalização de chamada com os terminais e pode processar a
sinalização de chamada propriamente dita. De modo alternativo, o gatekeeper
pode direcionar os terminais a conectar o canal de sinalização de chamada
diretamente entre eles, fazendo com que o gatekeeper não precise realizar a
sinalização de controle de chamada H.225.
• Autorização de chamada: Através do uso da sinalização H.225, o gatekeeper
pode rejeitar chamadas de um terminal em virtude de falha de autorização. As
razões para rejeição podem incluir acesso restrito para/de terminais
particulares ou gateways, e acesso restrito durante certos períodos de tempo.
• Administração de largura de banda: Controle do número de terminais H.323
permitidos a acessar simultaneamente a rede. Através da sinalização H.225.0
o gatekeeper pode rejeitar chamadas de um terminal devido a limitações de
largura de banda. Isso ocorre quando o gatekeeper determina que não há
largura de banda suficiente para suportar uma ligação.
• Administração de chamadas: O gatekeeper pode manter uma lista de
chamadas em curso, pois esta informação pode ser necessária para indicar se
um terminal está ocupado e também para prover informação pertinente à
administração de largura de banda disponível.
• Modificação de endereço de alias: O gatekeeper pode retornar um endereço
de alias modificado. Se o gatekeeper retorna um endereço de alias em um
ACF, o terminal deverá utilizar o endereço de alias para estabelecer a
conexão.

2.2.5. Características de Conferência Multiponto

Conferência multiponto é um tipo de chamada onde estão envolvidos três ou mais

terminais. Para este tipo de chamada ocorrer, são necessárias três entidades: MC,
MCU e MP (não obrigadas a estarem todas na mesma chamada).

O controlador multiponto (MC) provê funções de controle para suporte a

conferência, entre três ou mais terminais em uma conferência multiponto. O

32
controlador multiponto deve negociar e administrar as capabilidades que cada
terminal possui e que pode utilizar em uma conferência. Desta forma o MC
determina o SCM (modo de comunicações selecionado) para a conferência, que
deverá ser comum a todos os terminais envolvidos na conferência.

Na inicialização de uma conferência multiponto, um terminal se tornará conectado a

um MC em seu canal de controle H.245. Esta conexão pode ocorrer:

• Via uma conexão explícita com o MCU.

• Via uma conexão implícita com o MC dentro de um gatekeeper.
• Via uma conexão implícita com o MC dentro de outro terminal ou gateway
na conferência multiponto.
• Via uma conexão implícita por um gatekeeper até um MCU.

A escolha do modo de conferência (centralizada ou descentralizada) ocorre depois da

conexão com o MC, utilizando-se sinalização H.245. A escolha do modo de
conferência pode ser limitada pelas capabilidades dos terminais envolvidos ou pelo
próprio MC.

Um MC pode estar localizado dentro de um terminal, gatekeeper, gateway ou MCU,

conforme figura a seguir.

Figura 9 - Possíveis localizações de um MC ou MP (fonte: ITU-T)

O MP (processador multiponto) é responsável por receber áudio, vídeo ou fluxos de

33
dados dos terminais envolvidos em uma conferência centralizada ou híbrida. O MP
processa estes fluxos de mídia e retorna-os aos terminais.

O MCU é um terminal que provê suporte para conferências multiponto. A estrutura

do MCU é formada por um MC e nenhum ou mais MP’s.

2.3. SINALIZAÇÃO DE CHAMADAS

Sinalização de chamadas são as mensagens e procedimentos utilizados para

estabelecimento de chamadas, requisição de alteração na largura de banda de uma
chamada, requisição de informação de estado dos terminais em uma chamada e
desconexão de chamada. A sinalização de chamadas utiliza-se de mensagens H.225.

2.3.1. Endereçamento

É mandatório que o terminal possua pelo menos um endereço de rede (IP, por
exemplo), que vai identificar o mesmo na rede onde está localizado. Para cada
endereço de rede, cada terminal H.323 pode ter vários identificadores TSAP,
possibilitando a multiplexação de vários canais, compartilhando o mesmo endereço
de rede.

Terminais possuem um identificador TSAP conhecido e definido: o identificador

TSAP do canal de sinalização de chamada. O mesmo ocorre com os gatekeepers, que
possuem o identificador TSAP do canal RAS. Os gatekeepers possuem também um
endereço multicast definido: o Discovery Multicast Address. Para o canal de controle
H.245, canais de áudio, canais de vídeo e canais de dados, os terminais e demais
entidades H.323 devem utilizar-se de identificadores TSAP dinâmicos. O mesmo
acontece para os canais de sinalização de chamada, onde os gatekeepers devem se
utilizar de identificadores TSAP dinâmicos também.

Outro tipo de endereçamento utilizado é o alias. Um terminal pode ter um ou mais

34
alias associados a ele. O alias representa o terminal propriamente dito ou
conferências que o terminal está hospedando no momento, e é uma forma alternativa
de identificar um terminal. A representação de alias inclui dialledDigits,
partyNumber e H.323 ID (nomes alfanuméricos ou parecidos com endereço de
correio eletrônico).

Quando um gatekeeper não está presente em um determinado sistema, o terminal

chamador deve endereçar a chamada diretamente, utilizando o endereço de transporte
do canal de sinalização de chamada do terminal chamado. E quando existe um
gatekeeper no sistema, o terminal chamador pode escolher entre endereçar o terminal
chamado pelo endereço de transporte, do canal de sinalização de chamada ou
simplesmente pelo alias, que é posteriormente traduzido para o endereço de
transporte. Uma das maneiras de endereçamento utilizadas de alias é através do ID
de URL, que utiliza esquemas no padrão URL.

2.3.2. Canal RAS (Registro, Admissão e Estado)

O canal RAS é utilizado para transportar mensagens utilizadas no processo de

descoberta de gatekeeper e processos de registro de terminais, que associam os alias
de cada terminal aos respectivos endereços de transporte do canal de sinalização de
chamada. Todas as mensagens do canal RAS são transmitidas em pacotes UDP, ou
seja, não orientado a conexão. Tipicamente, equipamentos que realizam este tipo de
sinalização adotam as portas 1719 (unicast) e 1718 (multicast) como padrão.

Na descoberta de gatekeeper, o terminal envia mensagens multicast de descoberta de

servidor, perguntando “quem é meu gatekeeper?” (mensagem de Gatekeeper
Request) e os servidores habilitados respondem com uma mensagem “eu posso ser
seu gatekeeper” (mensagem de Gatekeeper Confirmation), que contêm o endereço de
transporte do canal RAS do Gatekeeper. O terminal então escolhe o servidor em que
deseja se registrar. Em caso de rejeição, a mensagem Gatekeeper Reject é enviada
pelo gatekeeper ao terminal.

35
Neste momento, ao se registrar em um servidor, o terminal se junta à uma “Zona” e
informa ao gatekeeper seu endereço de transporte e alias. Assim, quando outros
terminais desejarem iniciar uma chamada, todos saberão a localização deste terminal
registrado.

2.3.3. Canal de Sinalização de Chamada

O canal de sinalização de chamada é utilizado para transporte de mensagens de

controle de chamada H.225.0, em um canal orientado à conexões. Em redes onde não
há a presença de um gatekeeper os terminais trocam mensagens de sinalização de
chamada diretamente uns com os outros. Em redes com a presença de um
gatekeeper, as mensagens iniciais dos terminais são trocadas com o gatekeeper,
utilizando-se o endereço de transporte do canal RAS. Enquanto as mensagens iniciais
de admissão são trocadas, o gatekeeper indica em mensagens ACF se o terminal
deve enviar as mensagens de sinalização diretamente ao outro terminal ou se elas
devem ser intermediadas pelo próprio gatekeeper.

Múltiplas chamadas simultâneas podem ser sinalizadas pelo mesmo canal de

sinalização de chamadas. Isso pode ser feito através do valor de referência de
chamada, que associará uma mensagem de sinalização de chamada a uma chamada.

2.3.4. Valor de Referência de Chamada

Toda chamada deve conter um CRV (Call Reference Value) ou valor de referência de
chamada, um para o canal RAS e outro independente para o canal de sinalização de
chamada. O CRV deve estar presente nas mensagens trocadas entre duas entidades
(terminal-terminal ou terminal-gatekeeper) relacionadas à mesma chamada. Quando
um terminal convida uma terceira entidade a participar da mesma conferência, este
canal de sinalização deve conter um novo CRV.

36
2.3.5. Identificação de Chamada

O Call ID ou identificação de chamada, ao contrário do CRV, não altera seu valor

durante uma chamada. O Call ID é um valor, diferente de zero, criado pelo terminal
que iniciou a chamada. Ele identifica a chamada com as mensagens associadas a ela.
É utilizado para associar todos os canais RAS e de sinalização de chamadas
relacionadas à mesma chamada.

2.3.6. Identificação de Conferência e Objetivo de Conferência

O CID (Conference ID) é um valor diferente de zero criado pelo terminal chamador e
passado em várias mensagens H.225.0. O CID identifica qual a conferência na qual
as mensagens estão envolvidas. Assim, todas as mensagens pertencentes à mesma
conferência possuirão o mesmo CID.

O parâmetro ConferenceGoal ou Objetivo de Conferência indica a intenção da

chamada. São elas:

• create: Para criar uma nova conferência.

• join: Para se juntar a uma conferência em andamento.
• invite: Convida um novo terminal a se juntar a uma conferência em
andamento.
• capability-negotiation: negocias as capabilidades para uma conferência
H.332 posterior.
• callIndependentSupplementaryService: transporte de serviços suplementares
APDUs.

2.3.7. Capacidade de Chamada de Terminal

A capacidade de chamada indica a aceitação de capacidade de um terminal para cada

37
tipo de chamada que um terminal deverá suportar (voz, dados T.120, H.320, etc.).
Um terminal pode reportar sua capacidade de chamada por meio de várias
mensagens H.225.0, para auxiliar o gatekeeper a rotear chamadas. Já um gateway
reporta sua informação de capacidade de chamada para auxiliar um gatekeeper a
realizar balanceamento de carga através de gateways e para diminuir o número de
tentativas de chamadas falhas.

2.3.8. Serviços de Identificação de Chamador

O serviço de identificação de chamador é um recurso que consiste em transmitir

informações referentes à apresentação ou à restrição de informações, entre os
terminais ou entre um gatekeeper e um terminal. Os tipos de identificação são:

• Número do chamador.
• Número conectado.
• Número chamado.
• Número ocupado.

2.4. PROCEDIMENTOS DE SINALIZAÇÃO DE CHAMADAS

2.4.1. Fase A – Call Setup

O call setup ocorre antes do fluxo da chamada ser estabelecido entre duas partes. É
realizado através de mensagens de controle de chamada definidas na recomendação
H.225.0 e pode acontecer de várias maneiras, de acordo com o cenário utilizado,
explicado a seguir.

Quando dois terminais não estão conectados em nenhum gatekeeper e querem se

comunicar, a troca de sinalização é realizada diretamente de um terminal ao outro. O
terminal 1 (endpoint 1) envia a mensagem de setup (1) ao terminal chamado, para o
(conhecido) identificador TSAP do canal de sinalização de chamada do terminal 2

38
(endpoint 2). O terminal chamado responde com as mensagens de call proceeding
(2), alerting (3) e connect (4), ilustrados na figura 10.

Figura 10 - Call setup básico sem gatekeeper (fonte: ITU-T)

Com dois terminais registrados no mesmo gatekeeper existem duas formas dos
mesmos realizarem a troca de sinalização. A primeira é quando os terminais se
comunicam diretamente, ou seja, as mensagens de sinalização de chamada são
enviadas de um terminal diretamente ao outro terminal, sem intermediação do
gatekeeper. Desta forma, somente as mensagens iniciais ARQ (Admission Request,
mensagem de requisição para especificação da largura de banda), ACF (Admission
Confirm, mensagem de confirmação) e ARJ (Admission Reject, mensagem de
refeição), todas elas mensagens RAS, serão trocadas diretamente com o gatekeeper.

Figura 11 - Terminais registrados no mesmo gatekeeper, com sinalização direta (fonte: ITU-T)

39
Quando o gatekeeper age como intermediador de toda sinalização, todas as
mensagens serão roteadas pelo gatekeeper, antes de chegar ao terminal chamado.

Figura 12 - Terminais registrados no mesmo gatekeeper, com sinalização roteada (fonte: ITU-T)

Na figura 13 o terminal chamador irá trocar a sinalização RAS com o gatekeeper

(onde está registrado) e a sinalização de chamada será transmitida diretamente entre
os terminais.

Figura 13 - Somente terminal chamador registrado, sinalização direta (fonte: ITU-T)

Caso a sinalização escolhida seja a roteada, o gatekeeper vai intermediar as

mensagens de sinalização de chamada, mas não irá trocar mensagens RAS com o

40
terminal chamado.

Figura 14 - Somente terminal chamador registrado, sinalização roteada (fonte: ITU-T)

Na sinalização direta, o terminal 1 (endpoint 1), que não está registrado em nenhum
gatekeeper, envia a mensagem de setup (1) diretamente ao terminal 2 (endpoint 2),
este sim registrado em um gatekeeper. Como o terminal 2 aceitou a chamada, ele
envia a mensagem call proceeding (2) e em seguida inicia a troca de mensagens RAS
com o gatekeeper no qual está registrado. Na seqüência as mensagens alerting (5) e
connect (6) finalizam a sinalização.

Figura 15 - Chamador registrado no gatekeeper, sinalização direta (fonte: ITU-T)

Quando um terminal externo chama um terminal dentro de uma rede através de um

gateway, este se comporta igual a um terminal dentro da mesma rede, como se

41
estivesse em uma chamada terminal-terminal. O gateway deverá agir como um
terminal, realizando toda conversão necessária para que o terminal externo faça
corretamente a sinalização com o terminal da rede.

O mesmo ocorre no caso de conferências do tipo multiponto centralizada. Todos os

terminais devem trocar sinalização diretamente com o MCU e este vai fazer a
sinalização de chamada como se fosse um terminal simples sinalizando com outro
terminal.

2.4.2. Fase B – Comunicação Inicial e Troca de Capabilidade

Após a troca de mensagens de setup da fase “A”, os terminais devem estabelecer a

abertura do canal de controle H.245, se for o intuito de ambos os terminais. A
abertura deste canal destina-se a troca de capabilidade e à abertura dos canais de
mídia. As definições de capabilidade por sinal são as primeiras mensagens enviadas
pelo canal de controle H.245, através da transmissão de mensagens do tipo
terminalCapabilitySet.

A determinação de mestre-escravo deve se seguir após a troca de capabilidade entre

os terminais através das mensagens MasterSlaveDetermination ou
MasterSlaveDeterminationAck (a que for mais apropriada). A determinação mestre-
escravo é importante para casos onde a capabilidade de MC (Multipoint Conference)
está presente nos dois terminais em comunicação. Assim é possível determinar qual
MC será a ativa em uma conferência.

Com o objetivo de conservar recursos, sincronizar sinalização de chamada e controle

e reduzir o tempo do setup das chamadas foi definido um procedimento que torna
possível encapsular mensagens H.245 em mensagens do canal de sinalização
H.225.0, ao invés de estabelecer um canal H.245 separado. Esse processo é também
chamado de tunelamento. O tunelamento pode ser cancelado a qualquer momento
por ambos os terminais, fazendo com que as mensagens comecem a ser transmitidas
em um canal separado H.245.

42
Quando não existe a necessidade de se enviar mensagens H.225.0 e uma mensagem
H.245 precisa ser enviada, então é enviada a mensagem H.225.0 Facility, com o
parâmetro reason contendo transportedInformation.

O tunelamento é ativo quando a primeira mensagem H.225.0 trocada entre os dois

terminais é enviada, uma mensagem H.225.0 com o parâmetro h245Tunnelling
marcado como TRUE.

2.4.3. Fase C – Estabelecimento de Comunicação Áudio Visual

Após a troca de capabilidades e a determinação de mestre-escravo entre os terminais,

os procedimentos da recomendação H.245 serão utilizados para abrir canais lógicos
para os vários fluxos de informação. Os fluxos de áudio e vídeo serão transportados
por identificadores TSAP dinâmicos, utilizando-se de um protocolo não orientado à
conexão (UDP). Já as comunicações de dados serão transmitidas por um protocolo
orientado à conexão (TCP).

No estabelecimento dos canais lógicos, vários tipos de procedimentos (descritos na

recomendação H.245) podem ocorrer de acordo com o tipo, topologia e finalidade da
chamada. Alguns podem ser obrigatórios e outros opcionais como, por exemplo, a
mudança de modo em um canal lógico, que minimiza a falha do áudio. Outro
exemplo seria a associação de um canal lógico com um fluxo RTP dentro de uma
conferência multiponto.

2.4.4. Fase D – Serviços de Chamadas

Existem seis tipos de serviços diferentes que podem ser utilizados durante o
transcorrer de uma chamada qualquer. São eles:

• Alteração de largura de banda: a largura de banda é inicialmente estabelecida

43
 e aprovada pelo gatekeeper durante as sinalizações de admissão. Depois de
iniciada a troca de fluxo de informação, qualquer um dos terminais ou o
próprio gatekeeper, mesmo em uma conferência a três ou mais participantes,
pode solicitar a alteração de largura de banda. Recomenda-se este tipo de
alteração quando um terminal for utilizar a largura de banda reduzida por um
longo período de tempo, liberando desta forma largura de banda para outras
chamadas concomitantes.
• Estado: utilizado pelo gatekeeper para determinar se um determinado
terminal está ativo ou não, ou ainda se entrou em estado de falha. Através de
uma seqüência de mensagens IRQ e IRR (H.225.0) enviada aos terminais
(intervalo determinado pelos fabricantes dos terminais) é possível saber o
estado em que cada terminal conhecido se encontra no momento.
• Expansão de conferência ad hoc: este procedimento é opcional para terminais
e gateways, mas obrigatório para um MC. Através deste procedimento é
possível expandir uma conferência ponto a ponto para uma multiponto ad
hoc, onde um dos terminais no mínimo precisa conter um MC.
• Serviços suplementares: os serviços suplementares foram criados
originalmente para centrais telefônicas privadas baseadas em comutação de
circuito. Na série de recomendações H.450.x do ITU-T, um quantidade
considerável destes serviços foi especificada como serviços básicos,
implementados agora em redes baseadas em comutação de pacotes [6].
Alguns destes serviços são: transferência, redireção, retenção de chamada,
estacionamento de chamada, chamada em espera, etc.
• Cascateamento multiponto: o cascateamento acontece quando duas
conferências distintas são conectadas uma a outra, através do MC de cada
uma delas. Desta forma uma delas é determinada como MC mestre e a outra
como escrava. Uma vez estabelecida uma conferência cascateada, tanto o
terminal mestre como o escravo poderão convidar outro MC para participar
da conferência, mas somente poderá existir um MC mestre para cada
conferência cascateada.
• Pausa e re-roteamento por uma terceira parte: é um procedimento que permite
rotear ligações independentemente se o terminal possui suporte a serviço

44
 suplementar. É utilizado para facilitar anúncios de pré-conexão e também
para atrasar o estabelecimento de mídia H.245 quando o recurso de
localização de usuário por gatekeeper estiver sendo utilizado. Na pausa, o
terminal recebe uma mensagem H.245 onde ele ficará em estado de espera e
com todos os canais lógicos fechados, até que o terminal remoto envie outra
mensagem para terminar a pausa. Isso pode auxiliar uma entidade
anunciadora, por exemplo, a enviar fluxo de informação e não receber nada
do terminal em pausa.

2.4.5. Fase E – Finalização de Chamada

Uma chamada pode ser finalizada de duas maneiras: intermediada por um gatekeeper
ou simplesmente por sinalização entre dois terminais em comunicação direta.

45
3. PROTOCOLO SIP (IETF)

3.1. INTRODUÇÃO

O Session Initiation Protocol ou simplesmente SIP, é um protocolo de controle

baseado na camada de aplicação que estabelece, modifica e termina sessões
multimídia. Os cinco elementos principais do SIP são:

• Localização de usuário: determinação do sistema final a ser utilizado para

comunicação.
• Disponibilidade de usuário: determinação da parte chamada a estabelecer
comunicação.
• Capabilidade de usuário: determinação do tipo de mídia e dos respectivos
parâmetros a serem utilizados.
• Setup de sessão: determinação dos parâmetros de sessão a serem utilizados
pela parte chamadora e pela parte chamada, durante a fase de estabelecimento
da chamada.
• Administração de sessão: transferência e terminação de sessão, modificação
de parâmetros de sessão, chamada de serviços.

O protocolo SIP não é um sistema de comunicação verticalmente integrado. Para

uma completa arquitetura multimídia, outros protocolos IETF podem ser utilizados
(SDP, MEGACO, RTP, RTSP), embora o funcionamento e operações básicas do SIP
não dependam destes protocolos adicionais. O SIP também não suporta serviços, ou
melhor, ele provê somente premissas que podem ser utilizadas para implementar
diferentes serviços. Outro detalhe importante é que o SIP não realiza o controle de
conferência. Ele pode somente iniciar uma sessão SIP, mas o controle da conferência
deve ser realizado por um protocolo específico.

As informações contidas neste capítulo sobre SIP são baseadas em [2].

46
3.2. ESTRUTURA

O SIP é um protocolo dividido em camadas, listadas a seguir:

• A mais baixa camada é onde se encontra a sintaxe e codificação. Esta é

especificada utilizando-se a gramática BNF (forma de Backus-Naur).
• A segunda camada é a de transporte. Esta define como um cliente ou um
servidor envia requisições e recebe respostas através da rede. Todos os
elementos SIP contêm uma camada de transporte.
• A terceira camada é a de transação, componente fundamental do SIP. Uma
transação é uma requisição enviada por uma transação cliente (utilizando-se a
camada de transporte) para uma transação de servidor, assim como as
respostas a estas requisições. Esta camada lida com retransmissões da camada
de aplicação, casamento de respostas às requisições e expiração de tempo da
camada de aplicação. Qualquer tarefa que um UAC (User Agent Client)
cumpra é através de uma série de transações.
• A quarta camada se chama usuário transação (TU – Transaction User). Cada
um dos elementos SIP, exceto o stateless Proxy, é um TU. Quando um TU
deseja enviar uma requisição, ele cria uma instância de transação cliente e
repassa juntamente com o endereço IP de destino e porta, e assim transporta
para quem ele quer enviar a requisição.

3.3. DEFINIÇÕES

Para uma melhor compreensão da arquitetura SIP, os seguintes termos são de suma
importância ser conhecidos:

• Address-Of-Record: um AOR é um URI SIP ou SIPS que aponta para um

domínio com um serviço de localização que pode mapear um URI para outro
URI quando um usuário estiver disponível. Tipicamente o serviço de
localização é suprido pelos registros. Um AOR é freqüentemente considerado

47
 como o endereço público do usuário.
• Back-To-Back User Agent: entidade lógica que recebe uma requisição e a
processa como um UAS. Para saber como uma mensagem de requisição deve
ser respondida ele age como um UAC e gera requisições. Ao contrário do
servidor Proxy, ele mantêm o estado de diálogo e deve participar de todas as
requisições enviadas nos diálogos que se estabeleceram.
• Call Stateful: Um proxy é call stateful se ele retêm o estado para um diálogo
da requisição INVITE iniciadora até o BYE finalizador.
• Core: designa as funções específicas de um tipo particular de entidade SIP.
• Diálogo: Um diálogo é o relacionamento SIP ponto a ponto entre dois UAs
que persiste por algum tempo. Um diálogo é estabelecido por mensagens SIP,
como a resposta 2xx para uma requisição INVITE. Um diálogo é identificado
por um identificador de chamada, tag local e tag remoto.
• Downstream: É a direção de encaminhamento de mensagem de requisição
que vai do UAC ao UAS.
• Home Domain: é o domínio provendo serviços para um usuário SIP.
Tipicamente, este é o domínio presente no URI do AOR de um registro.
• Outbound Proxy: é um proxy que recebe requisições de um cliente, embora
este possa não ser o servidor resolvido pelo request-URI. Normalmente um
UA tem seu outbound proxy configurado manualmente, ou pode aprender a
localização de algum através de algum protocolo de descoberta.
• Proxy Server: entidade intermediária que atua tanto como servidor como
cliente (quando se propõem a fazer requisições em nome de outros clientes).
A função primordial do Proxy Server é roteamento, seu trabalho é garantir
que a requisição é enviada para outra entidade o mais próximo possível do
usuário alvo. Eles são úteis também para políticas de segurança (por exemplo,
para garantir que um usuário tenha ou não permissão para realizar
determinada chamada). Um Proxy interpreta e, se necessário, reescreve partes
específicas de uma mensagem de requisição, antes de encaminhar ela.
• Redirect Server: é um UAS que gera respostas 3xx para as requisições que
recebe, direcionando o cliente a contatar uma série de URIs alternativas.
• Registrar: é o servidor que aceita as requisições de REGISTER e armazena as

48
 informações que recebe no serviço de localização no domínio em que ele
atua.
• Sessão: Da especificação SDP: “Uma sessão multimídia é uma série de
remetentes e destinatários multimídia e os fluxos de dados que vão dos
remetentes aos destinatários. Uma conferência multimídia é um exemplo de
uma sessão multimídia” [7]. Como definido, a parte chamada pode ser
convidada diversas vezes, por diferentes chamadas, para uma mesma sessão.
Se o SDP for usado, uma sessão é definida pela concatenação dos nomes de
usuário, ID de sessão, tipo de rede, tipo de endereço e elementos do endereço
no campo origem.
• SIP Transaction: ocorre entre um cliente e um servidor e compreende todas
as mensagens da primeira requisição enviadas pelo cliente ao servidor, até
uma resposta final (1xx) enviada do servidor para o cliente. Se a requisição é
INVITE e a resposta final é diferente de 2xx, a transação também inclui um
ACK para a resposta. Um ACK para uma resposta 2xx a uma requisição
INVITE é uma transação separada.
• Stateful Proxy: entidade lógica que mantêm os mecanismos de estado de
transação do cliente e servidor, durante o processo de requisição, também
conhecido como transaction stateful proxy.
• Stateless Proxy: entidade lógica que não mantêm os mecanismos de estado de
transação do cliente e servidor. Um stateless Proxy encaminha qualquer
requisição que recebe de forma downstream e toda resposta que recebe de
forma upstream.
• Upstream: É a direção de encaminhamento de mensagem de resposta que vai
do UAS ao UAC.
• User Agent Client (UAC): entidade lógica que cria uma nova requisição e
então utiliza o mecanismo de estado de transação cliente para enviá-la. O
papel de UAC dura somente pela duração da transação. Em outras palavras,
se uma parte do software inicia uma requisição, ele atua como UAC pelo
tempo da duração daquela transação. Se receber uma requisição mais tarde,
ele assume o papel de UAS para o processo da transação.
• User Agent Server (UAS): entidade lógica que gera respostas a requisições

49
 SIP. Este tipo de resposta aceita, rejeita ou redireciona requisições. Este papel
dura apenas pelo tempo desta transação. Em outras palavras, se um pedaço de
software responde a uma requisição, ele atua como UAS pelo tempo da
duração daquela transação. Se ele gerar uma requisição mais tarde, ele
assume o papel de UAC para o processo desta transação.
• User Agent (UA): entidade lógica que pode atuar tanto como cliente como
servidor.

Os servidores de proxy, localização e registrar são entidades lógicas,

implementações podem combinar todos eles em um só aplicativo, como é o caso da
plataforma Asterisk.

3.4. MENSAGENS SIP

O SIP é um protocolo que atua na camada de aplicação e é baseado em texto (utiliza

a série de caracteres UTF-8). A similaridade de sintaxe das mensagens SIP com
mensagens HTTP/1.1 é muito grande, embora não possamos considerar o SIP uma
extensão do HTTP. Basicamente existem dois tipos de mensagens: requisição e
resposta.

Uma mensagem SIP genérica é formatada da seguinte forma:

[Linha inicial]
[Cabeçalho da mensagem]
[CRFL (carriage-return line-feed)]
[Corpo da mensagem]

3.4.1. Requisições

As mensagens de requisições distinguem-se por começarem com uma linha do tipo

50
requisição, constando o nome do método, o URI requisitado e a versão de protocolo.

Existem seis tipos de método: REGISTER para informações de registro de contato,

INVITE, ACK e CANCEL para estabelecimento de sessões, BYE para terminar
sessões e OPTIONS para consultar servidores sobre suas capabilidades. O URI
(Uniform Resource Indicators) requisitado é o usuário ou serviço a quem a
mensagem está sendo endereçada. Pode ser um URI SIP ou SIPS (SIP URI seguro).
Por fim a versão SIP utilizada na mensagem, SIP/2.0 (versão 2.0), por exemplo.

3.4.2. Respostas

Na primeira linha das mensagens de resposta encontramos o estado da linha ou status

line. Ela é formada pela versão do SIP utilizado, um código formado por três
caracteres numéricos (que indica o resultado de uma requisição realizada) e uma
pequena descrição textual acerca do significado do código numérico.

O primeiro dígito do código numérico indica a classe de resposta enviada:

• 1xx: Provisório, requisição recebida e continuando a processar a requisição.

• 2xx: Sucesso, a ação foi corretamente recebida, entendida e aceita.
• 3xx: Redireção, uma ação adicional é necessária para completar a requisição.
• 4xx: Erro de cliente, a requisição possui erro de sintaxe ou não pôde ser
processada no servidor de destino.
• 5xx: Erro de servidor, o servidor falhou ao responder uma requisição
aparentemente válida.
• 6xx: Falha global, a requisição não pôde ser processada em nenhum servidor.

3.5. COMPORTAMENTO GERAL DO USER AGENT

O conceito de user agent é definido como sendo um sistema final formado por um

51
UAC, que gera requisições e um UAS que responde estas requisições. O UAC é
capaz de gerar requisições baseado em estímulo externo (clique do mouse ou um
sinal vindo da PSTN) e também processar respostas recebidas. O UAS é capaz de
receber as requisições e gerar as respostas baseado na entrada de dados do usuário,
estímulo externo, o resultado da execução de um programa ou algum outro
mecanismo.

3.5.1. Comportamento do UAC

Uma requisição SIP válida formulada por um UAC deve conter no mínimo os
seguintes parâmetros:

• To – especifica o recipiente lógico de destino da requisição, ou o AOR do

usuário ou recurso que é o destino de tal requisição.
• From – especifica a identidade lógica do remetente da requisição, o AOR do
usuário remetente. Opcionalmente pode-se colocar o nome de exibição a
frente da identidade (assim como no To).
• CSeq – serve como uma forma de identificar e ordenar transações. Ele
consiste de um número de seqüência e o método (o método deve ser igual ao
enviado na requisição).
• Call-ID – atua como um identificador único para agrupar uma série de
mensagens SIP. Este identificador precisa ser igual em todas as mensagens
enviadas tanto pelo UAC como pelo UAS em um diálogo. A forma
recomendada do call-id é “identificador@dominio.com.br”. Por exemplo,
f81d4faedads@dominio.com.br.
• Max-Forwards – serve para limitar o número de saltos que uma requisição
pode realizar em seu caminho até o destino.
• Via – este parâmetro serve para indicar o transporte utilizado para a transação
e identifica a localidade para onde a resposta deve ser enviada. Este
parâmetro é somente preenchido após o transporte a ser utilizado para
alcançar o próximo salto ser selecionado.

52
Uma vez computada a requisição, os procedimentos de DNS devem ser aplicados
para determinação do destino, a não ser que contrariem alguma política local.

O processamento das respostas por parte do UAC é primeiramente realizado pela

camada de transporte do SIP e depois passada para a camada acima, de transação.
Esta camada realiza o processamento da resposta e então repassa para a TU. A maior
parte das respostas processadas pelo TU dependem do método, mas existem alguns
comportamentos independentes do método:

• Erros da camada de transação.

• Respostas irreconhecíveis.
• Vias.
• Respostas 3xx.
• Respostas 4xx.

3.5.2. Comportamento do UAS

Quando uma requisição fora de um diálogo é processada por um UAS, existe uma
série de regras de processamento que são seguidas, independentemente do método
utilizado.

Se uma requisição for aceita, todas as mudanças de estado associadas com ela devem
ser realizadas. Se a requisição for rejeitada, as mudanças de estado não devem ser
realizadas.

O processamento de requisições por parte do UAS inicia com a autenticação e depois

inspeção de método. Se o método não for suportado o UAS deve gerar uma
mensagem de resposta 405 (método não permitido). Caso o método seja suportado o
processamento continua com a leitura do cabeçalho.

Com o cabeçalho analisado e compreendido pelo UAS, segue-se o processamento de

conteúdo, que é a leitura do corpo da mensagem.

53
Após a checagem inicial descrita acima, o processamento no UAS torna-se
dependente de método (REGISTER, OPTIONS, INVITE, BYE). A partir deste
momento inicia-se a geração da resposta por parte do UAS.

3.5.3. Comportamento do UAS stateless

Um UAS stateless é aquele que não mantêm estado de transação. Ele responde às
requisições normalmente, mas descarta qualquer tipo de estado que possa ter sido
retido depois de uma resposta ter sido enviada. Quando um UAS stateless recebe
uma retransmissão de requisição, ele gera uma resposta como se estivesse
respondendo a primeira instância da requisição (esse comportamento exclui um
stateless registrar).

A função do UAS stateless é necessária primeiramente para manipular requisições

não autenticadas, para a qual uma pergunta de desafio é criada. Se requisições não
autenticadas fossem manipuladas de forma a manter o estado da transação, desta
forma fluxos maliciosos de requisições não autenticadas poderiam criar grandes
quantidades de estado de transação que poderiam tornar lento ou até mesmo cessar o
processamento de chamadas em um UAS (conhecido como ataque de negação de
serviço ou DoS).

Algumas regras importantes para o UAS stateless:

• Não deve enviar mensagens de resposta provisórias (1xx).

• Não deve retransmitir respostas.
• Deve ignorar requisições ACK e CANCEL.
• O cabeçalho da resposta deve ser gerado na forma stateless, gerando o
mesmo tag para a mesma requisição de maneira de maneira consistente.

54
3.6. CANCELANDO UM REQUEST

Para o cancelamento de uma requisição enviada, utiliza-se o método CANCEL. A

requisição CANCEL solicita ao UAS que pare de processar determinada requisição
previamente enviada e que gere uma resposta de erro para esta requisição. Um
CANCEL não vai ter efeito sobre uma requisição já processada pelo UAS.

Ele é utilizado e recomendado para requisições INVITE, que podem demorar um

longo período de tempo para serem respondidas. O CANCEL pode ser enviado a
partir de um UAC e um proxy.

3.7. REGISTROS

Quando um usuário quer iniciar uma sessão com outro usuário, o SIP deverá
descobrir em qual host este usuário está alcançável. Para que isso ocorra, os
elementos do SIP consultam um serviço abstrato chamado location service, que
provê bindings de endereços de um determinado domínio. Esses bindings de
endereço mapeiam um SIP URI recebido, apontando para um ou mais URIs, que de
alguma forma estão mais próximos do usuário final.

O registro funciona como um mecanismo que irá alimentar a base de dados do

location service, que armazenará as informações obtidas através dos registros
realizados. Em um registro é mandatório haver uma requisição REGISTER destinada
a um UAS especial chamado registrar.

Um registrar funciona como uma interface de entrada para um location service de

determinado domínio, lendo e escrevendo mapeamentos baseados no conteúdo das
requisições REGISTER. O location service é então tipicamente consultado por um
servidor proxy que é responsável por rotear requisições para o domínio.

As implementações de um location service não são especificadas na RFC do SIP,

mas um registrar deve ter a capacidade de escrever e ler dados deste location

55
service, assim como um servidor de proxy ou de redireção deve poder ler os mesmos
dados.

Figura 16 - Exemplo de requisição REGISTER (fonte: IETF)

3.8. INFORMAÇÕES DE CAPABILIDADE

O método utilizado para solicitar informações de capabilidade é o OPTIONS. Este

método é enviado de um UA para outro UA para descobrir informações sobre os
métodos suportados, tipos de conteúdo, ramais, codec's, etc, de cada um dos UA
envolvidos, sem iniciar o ring para a parte chamada, ou seja, ainda na fase de
estabelecimento de chamada.

Figura 17 - Exemplo de requisição OPTIONS (fonte: IETF)

56
 Figura 18 - Exemplo de resposta OPTIONS (fonte: IETF)

3.9. DIÁLOGOS

Um diálogo pode ser definido como uma relação SIP ponto a ponto entre dois UAs,
que persiste por um determinado tempo. Esse tipo de relação colabora com o
seqüenciamento de mensagens entre UAs e o correto roteamento de requisições e
respostas entre os pontos.

A identificação do diálogo é representada pelo call-ID, uma marcação (tag) remota e

uma local. Um ID de diálogo não é o mesmo em cada um dos UAs envolvidos no
diálogo. A marcação local é idêntica a marcação remota, mas devemos considerar
estas marcações como tokens que facilitam a geração de IDs únicos de diálogo.

Um ID de diálogo é também associado com todas as respostas e qualquer requisição

que contenha uma marcação no campo To. Dependendo se o UA é um UAS ou um
UAC, ele tem a computação do ID de diálogo diferente. Para o UAC, o call-ID do ID
de diálogo é o call-ID da mensagem, a marcação remota é igual à marcação no
campo To e a marcação local é igual à marcação do campo From. No UAS, as
marcações são o contrário.

Um diálogo contém certos pedaços de estado necessários para futuras transmissões

de mensagem dentro do diálogo. Este estado consiste em:

57
 • ID de diálogo
• Número de seqüência local
• Número de seqüência remota
• URI local
• URI remoto
• Target remoto
• Um flag booleano chamado “secure”
• Route Set (lista de URIs ordenadas, que são servidores que necessitam serem
transversos para enviar uma requisição a um ponto)

3.10. SESSÃO

Uma sessão (áudio, vídeo ou jogo) é estabelecida depois que um UA gera uma
requisição INVITE para um servidor. A requisição pode ser encaminhada por algum
proxy, eventualmente chegando a um ou mais UAS’s que podem potencialmente
aceitar o convite. Estes UAS’s podem aceitar o convite depois de algum tempo
(significando que a sessão está para ser estabelecida) com o envio de mensagens de
resposta 2xx. Se o convite não foi aceito, mensagens 3xx, 4xx, 5xx e 6xx serão
enviadas ao UAC, dependendo da razão da rejeição. Depois de enviar a resposta
final, o UAS pode ainda enviar mensagens provisórias do tipo 1xx para advertir o
UAC do progresso de contato com a parte chamada.

Devido ao tempo prolongado que um UAC possa demorar a receber uma mensagem
final, os mecanismos de confiabilidade para as transações INVITE diferem de outras
requisições como OPTIONS. Para cada resposta final recebida, o UAC deve enviar
um ACK. Quando a resposta final é entre 300 e 699, o processamento do ACK é
realizado na camada de transação e segue uma série de regras. Para respostas 2xx, o
ACK é gerado pelo core do UAC.

Uma resposta 2xx para um INVITE estabelece uma sessão e também cria um diálogo
entre os UA’s. Quando diversas respostas 2xx são recebidas de diferentes UA’s
remotos, cada mensagem 2xx estabelece um diálogo diferente, que serão parte da

58
mesma chamada.

Um sessão pode ser alterada também, o que envolve mudança de endereço ou porta,
adição ou remoção de fluxo de mídia, entre outras. Isso ocorre quando um novo
INVITE é enviado no mesmo diálogo que estabeleceu a sessão, este procedimento é
também conhecido como re-INVITE.

Para terminar uma sessão existem três maneiras, a primeira através do recebimento
de qualquer mensagem de resposta que não seja 2xx, a segunda maneira é pelo envio
da requisição BYE e a terceira pelo envio da requisição CANCEL, que pode ocorrer
quando determinado UAS tome muito tempo para enviar uma resposta final ao UAC.

3.11. PROXY

Um proxy SIP é um elemento que roteia requisições para UAS’s e respostas para
UAC’s. Uma requisição, por exemplo, pode passar por diversos servidores proxy em
sua trajetória até o UAS. Cada um destes servidores realizarão decisões de
roteamento, modificando a requisição antes de encaminhá-la para o próximo servidor
proxy. As respostas virão no mesmo caminho inverso, passando por todos os
servidores da ida.

3.11.1. Stateful proxy

Um proxy opera em modo stateful quando ele guarda informações de estado de

transação, sobre cada uma das requisições recebidas e encaminhadas após
processamento. A informação armazenada é utilizada como parâmetro no
processamento de futuras mensagens associadas com esta requisição.

Em modo stateful, o proxy é um mecanismo de processamento de transações SIP.

Logicamente falando, um proxy stateful possui uma transação de servidor associada
com uma ou mais transações cliente, através de um componente de processamento de

59
proxy de camada superior, conhecido como proxy core.

Figura 19 - Modelo de Proxy Stateful (fonte: IETF)

A mensagem de requisição, após ter sido processada pela transação de servidor, é

passada ao proxy core, que vai determinar para onde rotear a requisição, escolhendo
uma ou mais localizações de próximo-salto. Uma requisição sainte é processada para
cada localização de próximo-salto pela própria transação associada. O proxy core
coleta as respostas das transações de cliente e usa-as para enviar respostas para a
transação de servidor.

Um proxy stateful precisa realizar as seguintes tarefas para todas as requisições que
receber:

• Validar a requisição
• Pré-processar informações de roteamento
• Determinar para onde vai a requisição
• Encaminhar a requisição para cada local determinado
• Processar todas as respostas

60
3.11.2. Stateless proxy

Quando um proxy está no modo stateless, ele simplesmente age como um

encaminhador de mensagens. Muito do processamento executado em um stateful
proxy é igual a um stateless proxy.

Um stateless proxy não têm noção nenhuma de transação. Ele coleta as mensagens
diretamente da camada de transporte e, como resultado, não retransmite mensagens
por conta própria. Ele pode somente encaminhar todas as retransmissões que recebe
apenas, pois este tipo de proxy não terá a capacidade de discernir um retransmissão
de uma mensagem original. Agindo de forma stateless ele também não pode enviar
nenhuma mensagem provisória como um TRYING (100), ao contrário do proxy
stateful.

3.12. TRANSAÇÕES

O SIP é um protocolo transacional, interações entre componentes acontecem em uma

série de trocas de mensagens independentes. Uma transação consiste em uma
mensagem de requisição e qualquer resposta para a mesma, o que inclui uma
mensagem provisória ou uma mensagem final.

As transações possuem o lado cliente e o lado servidor, um envia a mensagem e o

outro responde, respectivamente. O lado cliente é chamado transação cliente e o lado
do servidor transação servidor. Estas transações são funções lógicas embutidas em
qualquer número de elementos. Elas existem em UA’s e servidores stateful proxy.
No exemplo da figura 20 o UAC executa uma transação cliente e seu servidor de
outbound proxy executa uma transação de servidor. Este servidor por sua vez executa
uma transação cliente através de uma mensagem de requisição com destino a
transação de servidor do servidor de inbound proxy. Este proxy executa o mesmo
procedimento com destino ao UAS, que enviará a mensagem de resposta, com os
processos acontecendo pelo caminha inverso.

61
 Figura 20 - Relacionamento de transações (fonte: IETF)

3.13. TRANSPORTE

A camada de transporte é responsável pela transmissão de requisições e respostas

sobre transportes de rede, incluindo a determinação do tipo de conexão a ser utilizada
para uma requisição ou resposta em caso de transportes orientados à conexão.

Esta camada é responsável pelo gerenciamento de conexões persistentes de

protocolos de transporte tais como TCP e SCTP, ou TLS sobre TCP/SCTP, incluindo
aqueles abertos a camada de transporte. Estas conexões são indexadas por uma tuplas
formada pelo endereço, porta e protocolo de transporte. Quando uma conexão é
aberta pela camada de transporte, este índice é definido com o endereço IP, porta e
transporte. Quando a conexão é aceita pela camada de transporte, este índice é
definido com o endereço IP, porta e transporte da fonte.

Note que, sendo o número de porta fonte efêmero ou selecionado por procedimentos,
conexões aceitas pela camada de transporte não serão reutilizadas, na maioria das
vezes. O resultado é que duas entidades proxy em uma relação ponto a ponto,
utilizando-se de transporte orientado à conexão, freqüentemente terão duas conexões
em curso, uma para cada direção nas transações.

62
3.14. CAMPOS DE CABEÇALHO

Abaixo se encontra a lista completa de campos de cabeçalho de mensagens SIP e

respectiva descrição, muito semelhante à semântica e sintaxe do HTTP/1.1,
característica do SIP.

• Accept: especifica certos tipos de mídia que são aceitáveis para uma resposta
[8]. Em caso de ausência, o servidor deve assumir o valor padrão
“application/sdp”. Em caso de parâmetro vazio, isso significa que nenhum
formato é aceitável.
• Accept-Encoding: similar ao accept, mas restringe a codificação de conteúdo
aceitável na resposta.
• Accept-Language: indica o idioma preferido nas frases de razão, descrições
de seção ou respostas de estado, carregadas como corpo de mensagem na
resposta.
• Alert-Info: em mensagens de INVITE, representa um tom de ring alternativo
para o UAS. Nas mensagens 180 (RINGING), representa um ringback
alternativo para o UAC.
• Allow: lista a série de métodos suportados pelo UA gerador da mensagem.
• Authentication-Info: provê autenticação mútua com HTTP digest.
• Authorization: contêm as credenciais de autenticação de um UA.
• Call-ID: identifica um convite particular único ou todos os registros de um
cliente em particular.
• Call-Info: provê informações adicionais sobre o chamador ou a parte
chamada. O parâmetro purpose determina a finalidade da informação.
• Contact: Provê o URI cujo significado depende da mensagem de requisição
ou resposta envolvida. Este campo pode conter o nome de exibição, uma URI
com todos os parâmetros URI e parâmetros de cabeçalho.
• Content-Disposition: descreve como o corpo da mensagem deve ser
interpretado.
• Content-Encoding: indica quais codificações de conteúdo foram aplicadas ao

63
 corpo da mensagem e quais mecanismos decodificadores devem ser
aplicados.
• Content-Language: idioma do conteúdo
• Content-Length: tamanho do corpo da mensagem, em número de bytes.
• Content-Type: indica o tipo de mídia do corpo da mensagem enviado ao
destinatário.
• CSeq: formado por um número decimal e o método utilizado, serve para
ordenar transações dentro de um diálogo.
• Date: contêm data e hora
• Error-Info: provê um ponteiro para informação adicional sobre a resposta de
estado de erro.
• Expires: tempo relativo expresso em segundos na qual a mensagem expirará.
• From: indica o iniciador da requisição, contendo o endereço do chamador.
• In-Reply-To: Enumera os Call-IDs que determinada chamada referencia ou
retorna.
• Max-Forwards: utilizado por qualquer método SIP para limitar o número de
proxies ou gateways que podem encaminhar a requisição para um próximo
servidor. O valor recomendado inicial é 70 (vai sendo decrementado).
• Min-Expires: convenciona o intervalo mínimo de atualização suportado pelos
elementos de estado de software gerenciados pelo servidor.
• MIME-Version: versão MIME
• Organization: nome da organização a qual o elemento SIP pertence.
• Priority: indica a urgência da requisição percebida pelo cliente.
• Proxy-Authenticate: contêm um desafio de autenticação (no sentido de
criptografia e autorização).
• Proxy-Authorization: permite ao cliente se identificar perante um proxy que
requer autenticação.
• Proxy-Require: indica recursos sensíveis aos proxies que precisam ser
suportados pelo proxy.
• Record-Route: inserido por proxies em requisições para forçar futuras
requisições em um diálogo a serem roteadas pelo proxy.
• Reply-To: este campo contêm um URI lógico de retorno que pode ser

64
 diferente do campo From de cabeçalho.
• Require: utilizado por UACs para avisar UASs sobre as opções que o UAC
espera que o UAS suporte, para processamento da requisição.
• Retry-After: valor em segundos utilizado em mensagens de resposta para
indicar quanto tempo o serviço é esperado permanecer indisponível para o
cliente requisitante.
• Route: força o roteamento de uma requisição para uma lista de proxies.
• Server: informação sobre o software utilizado pelo UAS para manusear a
requisição
• Subject: provê um sumário ou indica a natureza da ligação, permitindo
filtragem de ligação sem ter que analisar a descrição de sessão.
• Supported: enumera todas as extensões suportadas pelo UAC ou UAS.
• Timestamp: descreve quando um UAC enviou a requisição para o UAS.
• To: especifica o destinatário lógico da requisição.
• Unsupported: lista os recursos não suportados pelo UAS.
• User-Agent: contêm informações sobre o UAC originador da requisição.
• Via: indica o caminho tomado pela requisição até então e o caminho que deve
ser seguido no roteamento das respostas. O parâmetro Branch ID no valor de
cabeçalho do Via serve como um identificador de transação, utilizado pelos
proxies para detecção de loops.
• Warning: utilizado para carregar informações adicionais sobre o estado de
uma resposta. São enviados em mensagens de resposta e contêm um código
de três dígitos decimais, um host name e um texto de warning.
• WWW-Authenticate: contêm um desafio de autenticação.

3.15. CÓDIGOS DE RESPOSTA

Todos os códigos de resposta são consistentes com os códigos de respostas presentes

no HTTP/1.1. Algumas respostas do HTTP/1.1 não são apropriadas para o SIP e
vice-versa. O SIP, porém, implementa uma nova classe, a 6xx.

65
3.15.1. Respostas provisórias 1xx

As respostas provisórias, também conhecidas como respostas informativas, indicam

que o servidor contatado está executando alguma ação e não possui no momento uma
resposta definitiva para aquela requisição. Um servidor envia uma mensagem
provisória quando ele espera que a resposta definitiva demore mais que 200ms.

• 100 TRYING: indica que o servidor de próximo salto recebeu a requisição e

alguma ação não especificada está sendo tomada para esta chamada. Quando
o UAC recebe esta mensagem, automaticamente cessa o envio de INVITE.
• 180 RINGING: O UA receptor da mensagem INVITE está tentando alertar o
usuário.
• 181 CALL IS BEING FORWARDED: um servidor pode utilizar este estado
para indicar que a mensagem está sendo direcionada para uma série de
destinos diferentes.
• 182 QUEUED: a parte chamada está temporariamente indisponível, mas o
servidor decidiu enfileirar a chamada ao invés de rejeitá-la.
• 183 SESSION PROGRESS: convenciona informação sobre o progresso de
uma chamada que não foi por algum motivo classificada.

3.15.2. Resposta de sucesso 2xx

• 200 OK: indica que a requisição obteve êxito

3.15.3. Respostas de redireção 3xx

Respostas do tipo 3xx provêem informação sobre a nova localização do usuário ou

serviços alternativos que podem satisfazer a chamada.

• 300 MULTIPLES CHOICES: dado um endereço na requisição, esta resposta

66
 retorna diversas alternativas para o UAC selecionar sua preferida.
• 301 MOVED PERMANENTLY: o usuário requisitado não existe mais no
URI solicitado e deve tentar novamente através de um novo endereço dado
pelo campo de cabeçalho contact.
• 302 MOVED TEMPORARILY: equivalente ao 301, mas com prazo de
validade limitado, podendo ter seu tempo indicado por uma mensagem
EXPIRES ou o parâmetro expires no campo de cabeçalho contact.
• 305 USE PROXY: o recurso requisitado deve ser acessado por um proxy
dado pelo campo contact.
• 380 ALTERNATIVE SERVICE: a chamada não teve sucesso, mas existem
alternativas possíveis. A padronização desta mensagem é assunto para futura
discussão.

3.15.4. Resposta de falha 4xx

As respostas 4xx são definitivas e enviadas de servidores específicos. Este tipo de

requisição não pode ser enviada ao mesmo servidor seguidamente, mas sim para
servidores diferentes, onde pode receber uma resposta positiva.

• 400 BAD REQUEST: a requisição não foi compreendida devido a sintaxe

mal formada.
• 401 UNAUTHORIZED: a requisição requer autenticação de usuário. Este
tipo de resposta são emitidas por UASs e registrars.
• 402 PAYMENT REQUIRED: reservado para uso futuro.
• 403 FORBIDDEN: o servidor entendeu a requisição, mas nega-se a processá-
la. Autorização não resolve o problema dado por esta mensagem.
• 404 NOT FOUND: usuário não existe no domínio especificado.
• 405 METHOD NOT ALLOWED: o método especificado na request-line foi
entendido, mas não é permitido pelo URI requisitado.
• 406 NOT ACCEPTABLE: os recursos identificados pela requisição são

67
 somente capazes de gerar entidades de resposta que possuam características
de conteúdo não aceitáveis de acordo com o campo de cabeçalho accept,
enviado na requisição.
• 407 PROXY AUTHENTICATION REQUIRED: similar ao 401, porém
indica que o cliente necessita autenticar a si mesmo com o proxy.
• 408 REQUEST TIMEOUT: o servidor não conseguiu produzir uma resposta
em determinado intervalo de tempo.
• 410 GONE: o recurso requisitado não está mais disponível e nenhum
endereço de encaminhamento é conhecido.
• 413 REQUEST ENTITY TOO LARGE: o servidor está recusando-se a
aceitar a requisição porque o corpo da mensagem de requisição é maior do
que o servidor pode processar.
• 414 REQUEST-URI TOO LONG: o request-URI é muito longo para ser
interpretado pelo servidor.
• 415 UNSUPPORTED MEDIA TYPE: o servidor está negando a requisição
porque o formato do corpo da mensagem está em um formato não suportado
pelo servidor, pelo método requisitado.
• 416 UNSUPPORTED URI SCHEME: o esquema da URI é desconhecido ao
servidor.
• 420 BAD EXTENSION: o servidor não entende a extensão de protocolo
especificado em um campo de cabeçalho proxy-require ou require.
• 421 EXTENSION REQUIRED: o UAS necessita de uma extensão em
particular para processar a requisição, mas esta não está listada no campo de
cabeçalho supported da requisição.
• 423 INTERVAL TOO BRIEF: o servidor está negando a requisição por que o
tempo de expiração do recurso é muito curto.
• 480 TEMPORARILY UNAVAILABLE: o sistema final da parte chamada foi
contata com sucesso, mas a parte chamada não está disponível no momento
(não está autenticada, por exemplo).
• 481 CALL TRANSACTION DOES NOT EXIST: a requisição recebida não
pertence a nenhuma transação ou diálogo.
• 482 LOOP DETECTED: o servidor detectou um loop.

68
 • 483 TOO MANY HOPS: requisição recebida com o parâmetro Max-forwards
igual a zero.
• 484 ADDRESS INCOMPLETE: o request-URI foi recebido incompleto.
• 485 AMBIGUOUS: o URI requisitado é ambíguo e uma lista de URIs
possivelmente não ambíguas pode ser enviada no parâmetro contact.
• 486 BUSY HERE: o contato foi realizado com sucesso, mas a parte chamada
não pode ou não quer receber uma ligação adicional.
• 487 REQUEST TERMINATED: a requisição foi terminada por um BYE ou
CANCEL.
• 488 NOT ACCEPTABLE HERE: têm o mesmo significado da mensagem
606, mas somente se aplica ao recurso endereçado especificamente pelo
request-URI.
• 491 REQUEST PENDING: a requisição foi recebida pelo UAS que possui
uma requisição pendente dentro do mesmo diálogo.
• 493 UNDECIPHERABLE: a requisição recebida pelo UAS contêm o corpo
MIME criptografado e não possui a chave para decifrá-lo.

3.15.5. Resposta de falha de servidor 5xx

Estas respostas são enviadas pelo servidor quando o próprio cometeu um erro.

• 500 SERVER INTERNAL ERROR: o servidor encontrou uma condição

inesperada que o preveniu de processar determinada requisição.
• 501 NOT IMPLEMENTED: o servidor não possui implementado a facilidade
requisitada para processar a requisição.
• 502 BAD GATEWAY: o servidor, agindo como gateway ou proxy, recebeu
uma resposta inválida do próximo salto (servidor).
• 503 SERVICE UNAVAILABLE: o servidor está temporariamente incapaz de
processar a requisição devido a sobrecarga temporária ou manutenção de
servidor.
• 504 SERVER TIME-OUT: o servidor não recebeu resposta em tempo hábil

69
 de um servidor externo, para completar o processamento da requisição.
• 505 VERSION NOT SUPPORTED: o servidor não suporta, ou recusa-se a
suportar a versão do protocolo SIP que foi utilizada na requisição.
• 513 MESSAGE TOO LARGE: o tamanho da mensagem de requisição
excedeu as capacidades do servidor.

3.15.6. Respostas de falha global 6xx

As resposta 6xx indicam que o servidor possui uma informação definitiva sobre um
usuário em particular, não somente uma instância em particular indicada no request-
URI.

• 600 BUSY EVERYWHERE: o sistema final da parte chamada foi contatado

com sucesso, mas a parte chamada não deseja aceitar a ligação.
• 603 DECLINE: a máquina da parte chamada foi contata com sucesso, mas
explicitamente nega-se a aceitar a ligação.
• 604 DOES NOT EXIST ANYWHERE: o servidor têm autoridade suficiente
para indicar que o usuário indicado no request-URI não existe em lugar
nenhum.
• 606 NOT ACCEPTABLE: o UA foi contatado com sucesso, mas alguns
aspectos da descrição de sessão como mídia requisitada, largura de banda ou
estilo de endereçamento não foram aceitas.

3.16. USO DE AUTENTICAÇÃO HTTP

O protocolo SIP provê autenticação baseada no modelo HTTP, com um mecanismo

de desafio (challenge) stateless (não guarda estado). A autenticação provê garantia
de identidade da entidade SIP. Uma vez que o originador foi autenticado, o
destinatário pode decidir se aceita ou não a requisição em questão.

70
O mecanismo de autenticação digest provê autenticação de mensagem e proteção de
resposta somente, sem garantir a integridade ou confidencialidade da mensagem.
Medidas de proteção devem ser tomadas em níveis superiores de autenticação para
prevenir ataques ativos que possam modificar requisições e respostas SIP.

Devido à fraca segurança da autenticação “Básica”, o seu uso foi depreciado.

Servidores não devem aceitar credenciais utilizando-se do esquema de autenticação
“Básica” assim como não devem lançar “desafios” com este tipo de esquema.

O UAS utiliza a mensagem de resposta 401 (UNAUTHORIZED) para desafiar a

identidade de um UAC. Servidores de registrar e redirect também devem utilizar a
mensagem 401, ao contrário dos servidores proxy, que devem utilizar a mensagem
407 (PROXY AUTHENTICATION REQUIRED).

71
4. ANÁLISE COMPARATIVA ENTRE H.323 E SIP

O H.323 (ITU-T) e SIP (IETF) são os protocolos de sinalização para comunicação

multimídia mais utilizados do mercado atualmente. Cada um dos protocolos possui
origens bem distintas. Enquanto o H.323 foi criado pelo ITU-T, entidade que
padroniza tudo relacionado a telecomunicações, o SIP surgiu dos estudos do IETF,
organização direcionada a pesquisa e desenvolvimento da Internet.

O H.323 surgiu como um protocolo para comunicações multimídia em ambiente

LAN sem garantia de qualidade de serviço (QoS). Com o passar do tempo, as
pesquisas em torno do protocolo passaram a abordar métodos mais complexos,
inerentes a telefonia de Internet [9]. Este protocolo herda características de
sinalização do protocolo Q.931 ISDN, encontrada nas redes de circuito comutado.

O SIP foi desenvolvido pelo grupo de trabalho MMUSIC do IETF e possui uma
visão diferente do ITU-T, direcionada ao ambiente da Internet. Muitos dos campos
de cabeçalho, regras de codificação, códigos de erro e mecanismos de autenticação
são oriundos do HTTP. O SIP têm o objetivo de prover serviços equivalentes ao
H.323, mas com uma abordagem mais simplificada, baseada em serviços da web.

É importante ressaltar que as diferenças entre os dois protocolos não influenciam no

QoS para telefonia de Internet, visto que o protocolo que é responsável pelo
transporte da mídia é o RTP em ambos os casos [9].

4.1. COMPLEXIDADE

Não há dúvidas na maior complexidade do protocolo H.323 em relação ao SIP. A

herança das redes de circuito comutado faz com que a pilha de protocolos sob o
H.323 seja extensa. O SIP é mais simples, ao se espelhar em métodos oriundos do
HTTP.

O H.323 define algumas centenas de elementos enquanto o SIP possui apenas

72
algumas dezenas de cabeçalhos, cada um com menos parâmetros, porém contendo
mais informação. Uma simples interação SIP funciona com apenas quatro cabeçalhos
(To, From, Call-ID e CSeq) e três tipos de requisição (INVITE, ACK e BYE) [9].

O H.323 utiliza representação binária em suas mensagens, baseado no ASN.1 e PER

(packed encoding rules). O SIP utiliza-se de texto puro em suas mensagens, similar
ao HTTP [9]. Apesar das diferenças, ambos os protocolos utilizam UDP e TCP para
transporte das mensagens de sinalização.

A interação de inúmeros protocolos torna o H.323 complexo. O encaminhamento de

chamada requer a interação dos protocolos H.450, H.225.0 e H.245. Problemas de
tradução sobre firewalls foram uma constante nas primeiras versões do H.323, pois
estas entidades precisavam agir como proxies em nível de aplicação, analisando a
mensagem por completo para chegar aos campos desejados. Na última versão do
H.323 (versão 6), foram publicadas duas recomendações que normatizam os
procedimentos de firewall/NAT transversal, devido a demanda de telefonia
direcionada ao funcionamento em ambiente de Internet [10]. No H.323 a operação é
stateful, enquanto no SIP os elementos trabalham tanto em forma stateless ou
stateful, dependendo da operação [9].

4.2. EXTENSIBILIDADE E MODULARIDADE

A definição comumente conhecida por extensibilidade é a capacidade de se

promover expansões e melhorias em um sistema qualquer, com mínimos impactos
para isso. E este é um parâmetro de análise importante quando se comparam dois
protocolos de sinalização de voz sobre IP, pois a extensibilidade influencia
comercialmente e tecnicamente a escolha do protocolo a ser utilizado.

O SIP não define explicitamente os requisitos de compatibilidade entre versões, o

que resulta em redução do tamanho do código e menos complexidade. No entanto
pode ter o efeito adverso de novas versões não suportarem recursos de versões

73
anteriores. O H.323 por outro lado requer compatibilidade total de versões anteriores
com as novas versões, o que resulta em um código extenso para implementação [11].

A adição e evolução de recursos e serviços são consideradas mais flexíveis no SIP do

que no H.323. O SIP possui mecanismos de extensibilidade embutidos no código, é
baseado em texto e a maior parte de sua estrutura é modular. O H.323 é um tanto
complexo para definição de novos recursos e serviços, requerendo o código de
fabricantes para serem especificados [11].

A modularidade do SIP é notória quando analisamos a forma como outros protocolos

podem ser utilizados com o SIP, não necessitando de maiores modificações no
núcleo funcional do SIP. A interação de diversos protocolos sob o H.323 acaba
tornando-o mais fechado e menos maleável para interações com outros protocolos
[11].

Uma vantagem do H.323 é a utilização de codecs, que necessitam ser registrados

junto ao IANA (no caso do SIP) antes de qualquer implementação. No H.323 não
existe este tipo de requisito [11].

4.3. ESCALABILIDADE

O suporte a um número elevado de domínios possui visões diferentes de diversos

autores, mas existe equivalência entre SIP e H.323 [11]. O H.323 surgiu
originalmente para operar em simples segmentos de LAN. A necessidade de
implementações em ambientes mais complexos fez com que as forças tarefa do ITU-
T desenvolvessem recomendações que preenchessem as lacunas herdadas das
primeiras versões. O SIP por sua vez teve seu início já visando estes tipos de
ambientes. Hoje podemos dizer que ambos possuem os mesmos recursos para operar
em diversos domínios diferentes, cada um agindo de uma forma específica.

A habilidade de manipular um grande número de ligações é relativa. Ambos os

74
protocolos operam em modo stateful e stateless, sendo que o H.323 possui a maioria
das funcionalidades em modo stateful. O SIP utiliza em sua maior parte operações no
modo stateless, que teoricamente geram carga menor de processamento ao servidor,
mas como mencionado, é relativo e depende do tipo de aplicação e implementação.
O tipo de operação influencia na escalabilidade do protocolo, visto que quanto mais
estados uma entidade guardar, menor será a escalabilidade em vista da maior
complexidade envolvida [11].

4.4. SERVIÇOS

Os serviços suportados por ambos os protocolos são equivalentes, embora

implementados de formas diferentes. O H.323 padroniza os serviços através da
recomendação ITU-T H.450 enquanto o SIP não define explicitamente em sua RFC
principal, apenas em white papers e outras RFC informativas [11].

O tempo para aquisição de serviços também é equivalente nos dois protocolos,

quando utilizando UDP. A diferença é que o H.323 estabelece uma conexão de
backup via TCP paralelamente ao UDP, enquanto o SIP o faz seqüencialmente, após
falha do UDP [11].

4.5. SEGURANÇA

O H.323 utiliza-se da série de recomendações H.235, que foi reorganizada em várias

partes, hoje contando do H.235.0 até o H.235.9, listadas a seguir [1]:

• H.235.0 - H.323 security: Framework for security in H series (H.323 and

other H.245-based) multimedia systems.

• H.235.1 - H.323 security framework: Baseline security profile

75
 • H.235.2 - H.323 security framework: Signature security profile

• H.235.3 - H.323 security: Hybrid security profile

• H.235.4 - H.323 security: Direct and selective routed call security

• H.235.5 - H.323 security: Framework for secure authentication in RAS using

weak shared secrets

• H.235.6 - H.323 security framework: Voice encryption profile with native

H.235/H.245 key management

• H.235.7 - H.323 security framework: Usage of the MIKEY key management

protocol for the Secure Real Time Transport Protocol (SRTP) within H.235

• H.235.8 - H.323 security: Key exchange for SRTP using secure signaling
channels

• H.235.9 - H.323 security framework: Security gateway support for H.323

A necessidade de perfis de segurança no H.323 foi primeiramente suprida em

novembro de 2000, quando o ITU-T divulgou a recomendação H.235 versão 2, que
provia diferentes níveis de segurança, não definidos no H.323 em si. A mais nova e
importante adição à esta série foi o suporte a SRTP (Secure Real Time Transport
Protocol) [10].

O SIP suporta autenticação de chamador e chamado por meio de mecanismos HTTP.

A autenticação de segurança criptografada é suportada salto a salto por meio de
SSL/TSL, embora o SIP possa utilizar qualquer mecanismo de segurança da camada
de transporte ou similar HTTP, como SSH ou S-HTTP. O SIP também define
autenticação fim a fim e criptografia utilizando-se de PGP ou S/MIME [12].

76
5. CONCLUSÃO

O início do H.323 e SIP, como mencionado várias vezes neste trabalho, foram
distintos. O SIP surgiu com o intuito de ser uma versão ponto a ponto do protocolo
SAP (session announcement protocol) e o H.323 como um protocolo multimídia para
operação somente em segmentos de LAN [12]. Com a crescente demanda de novos
serviços e diferentes tipos de ambientes, as evoluções foram acontecendo
naturalmente, percorrendo caminhos diferentes até chegarem às versões atuais (que
continuam recebendo novos aperfeiçoamentos constantemente nos dois protocolos).

No meio acadêmico, o que se nota é que não há meio termo. Existem defensores para
cada um dos protocolos, porém poucos que aceitam os dois como protocolos
equivalentes. Em se tratando de mercado corporativo (principal foco dos dois
protocolos) nota-se um crescente número de fabricantes e desenvolvedores SIP.
Originalmente a maior parte das implementações corporativas era H.323. O SIP criou
uma espécie de marketing “pessoal” no mercado, enfatizando sua fácil
implementação e desenvolvimento. O que aconteceu na verdade é que o H.323
sofreu com a idéia de operar sobre redes distintas e domínios diversos durante muito
tempo. A dificuldade de transposição sobre firewalls e NAT limitou a utilização do
H.323 em redes com grande capilaridade de topologias. A demanda por serviços de
voz sobre IP trafegando em ambiente de Internet cresceu muito, chegando até mesmo
a usuários residenciais e o SIP preencheu esta lacuna, inicialmente com serviços
simples e eficientes.

Hoje os protocolos são quase equivalentes (e tendem a serem completamente

equivalentes), com algumas diferenças a serem observadas:

• Os serviços suplementares são mais rigorosamente definidos no H.323 [11], e

assim menos suscetíveis a problemas de interoperabilidade. A
compatibilidade entre versões é maior no H.323, além da tradicional
interoperabilidade com a PSTN, fruto da origem ITU-T.
• A complexidade do H.323 tornou o SIP uma alternativa de protocolo mais

77
 fácil de desenvolvimento e implementação por parte de fabricantes.
• Nota-se um crescente número de terminais SIP sendo comercializados por
custos menores que terminais H.323, popularizando ainda mais aplicações em
SIP, como a plataforma open-source Asterisk.
• A maioria esmagadora de fabricantes de equipamentos de videoconferência
utiliza a pilha de protocolos do H.323, sendo o SIP um protocolo ainda pouco
utilizado para tal aplicação.

78
6. REFERÊNCIAS BIBLIOGRÁFICAS

[1] ITU-T, H.323v6 Recommendation: packet-based multimedia communications

systems. 2006.

[2] IETF, Request for Comments 3261: session initiation protocol. 2002.

[3] LEOPOLDINO, Graciela Machado; MEDEIROS, Rosa C. Martins. H.323 – Um

padrão para sistemas de comunicação multimídia baseado em pacotes, 2001.
RNP News Generation. Disponível em
<http://www.rnp.br/newsgen/0111/h323.html>. Acesso em: 12 abril 2007.

[4] ITU-T, H.261 Recommendation: video codec for audiovisual services at p x 64

Kbits. 1993.

[5] PACKETIZER, T.120: a primer on the t.120 series standard. 2007. Disponível
em <http://www.packetizer.com/conf/t120/primer/>. Acesso em 8 junho 2007.

[6] KORPI, Markku; KUMAR, Vineet. Suplementary services in the H.323 IP

telephony network, 1999.

[7] IETF, Request for Comments 4566: session description protocol. 2006.

[8] IETF, Request for Comments 2616: hypertext transfer protocol – HTTP/1.1.
1999.

[9] SCHULZRINNE, Henning; ROSENBERG, Jonathan. A comparison of SIP and

H.323 for Internet Telephony, 1998.

[10] PACKETIZER, H.323 version 6: overview. 2008. Disponível em

<http://www.packetizer.com/ipmc/h323/whatsnew_v6.html>. Acesso em 13 maio
2008.

79
[11] PAPAGEORGIOU, Pavlos. A comparison of H.323 vs SIP. University of
Maryland at College Park, EUA. 2001.

[12] PACKETIZER, H.323 versus SIP: a comparison. 2008. Disponível em

<http://www.packetizer.com/ipmc/h323_vs_sip/>. Acesso em 13 maio 2008.

80