anÁlise comparativa dos protocolos h.323 e sip
DESCRIPTION
ABSTRACTThe objective of this work is to make a comparison of SIP (IETF) and H.323 (ITUT) 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.TRANSCRIPT
UNIVERSIDADE FEDERAL DO PARANÁ
SETOR DE CIÊNCIAS EXATAS – DEPARTAMENTO DE INFORMÁT ICA
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
2
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
3
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
4
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.
5
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.
6
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
7
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
8
LISTA DE TABELAS
Tabela 1 - Tipos de terminal para determinação mestre-escravo H.245 (fonte: ITU-T) 23
9
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
10
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
11
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
12
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
13
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.
14
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.
15
• 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
16
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
17
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
18
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.
19
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.
20
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).
21
• 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.
22
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
23
(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.
24
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.
25
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.
Figura 2 – Exemplo de topologia com gateways (fonte: autor)
Terminal H.323
Terminal da
SCN
Gateway (funções de conversão)
Gateway (funções de conversão)
Terminal H.323
Terminal da
SCN
26
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
27
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.
28
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.
29
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)
30
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)
31
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:
32
• 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
33
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
34
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
35
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.
36
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.
37
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
38
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
39
(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)
40
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
41
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
42
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.
43
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
44
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
45
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.
46
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].
47
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
48
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
49
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
50
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
51
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
52
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 é “[email protected]”. Por exemplo,
• 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.
53
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.
54
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.
55
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
56
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)
57
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:
58
• 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
59
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
60
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
61
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.
62
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.
63
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
64
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
65
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.
66
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
67
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
68
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.
69
• 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
70
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.
71
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).
72
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
73
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
74
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
75
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
76
• 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].
77
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
78
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.
79
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.
80
[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.