UNIVERSIDADE FEDERAL DO PARANÁ SETOR DE CIÊNCIAS EXATAS – DEPARTAMENTO DE INFORMÁTICA CURSO DE ESPECIALIZAÇÃO EM INFORMÁTICA ÊNFASE EM GERÊNCIA DE REDES DE COMPUTADORES
GERSON TAKASHI WATANABE
ANÁLISE COMPARATIVA DOS PROTOCOLOS H.323 E SIP
Curitiba - PR 2008
GERSON TAKASHI WATANABE
ANÁLISE COMPARATIVA ENTRE PROTOCOLOS H.323 E SIP
Trabalho apresentado à banca examinadora da Universidade Federal do Paraná, Departamento de Informática, para obtenção do certificado de Especialista em Informática – Ênfase em Gerência de Redes de Computadores. Orientador: Prof. Dr. Luciano Silva.
Curitiba - PR 2008
2
PARECER DE APROVAÇÃO MONOGRAFIA DE ESPECIALIZAÇÃO EM INFORMÁTICA ÊNFASE EM GERÊNCIA DE REDES DE COMPUTADORES PROGRAMA DE PÓS-GRADUAÇÃO EM INFORMÁTICA/UFPR
Declaramos que o aluno GERSON TAKASHI WATANABE entregou a versão final da sua Monografia de Especialização em Informática da Universidade Federal do Paraná, com Ênfase em Gerência de Redes de Computadores, intitulada Análise Comparativa Entre Protocolos H.323 e SIP.
Curitiba, 29 de maio de 2008.
NOME DO ORIENTADOR Professor Dr. Luciano Silva Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática Caixa Postal 19081 CEP 81531-990 - Curitiba-PR
NOME DO MEMBRO DA BANCA Professora Dra. Olga Regina Pereira Bellon Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática Caixa Postal 19081 CEP 81531-990 - Curitiba-PR
3
RESUMO
O objetivo deste trabalho é apresentar uma análise comparativa entre os protocolos de sinalização multimídia SIP (IETF) e H.323 (ITU-T). Primeiramente é realizado o embasamento teórico de cada um dos protocolos e ao final é realizado um comparativo das deficiências e virtudes de um em relação ao outro.
4
ABSTRACT
The objective of this work is to make a comparison of SIP (IETF) and H.323 (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.
5
SUMÁRIO 1. INTRODUÇÃO ........................................... .................................................................. .............................................. ...................................12 ............12 1.1. ITU-T E IETF .............................................. ..................................................................... ...........................................12 ....................12 1.2. OBJETIVO .............................................. ...................................................................... ...............................................13 .......................13 1.3. ESTRUTURA DO TRABALHO ........................................... ...........................................................13 ................13 2. PROTOCOLO H.323 (ITU-T).................................................... (ITU-T)........................................................................... ...........................14 ....14 2.1. INTRODUÇÃO......................................................................................14 2.2. ELEMENTOS DO H.323 ............................................ ................................................................... ...........................14 ....14 2.2.1. Fluxos de Informação .............................................. ..................................................................... ...............................14 ........14 2.2.2. Terminal..................................................................................................15 2.2.2.1 Características de vídeo ........................................... .................................................................. ...............................16 ........16 2.2.2.2 Características de áudio ........................................... .................................................................. ...............................17 ........17 2.2.2.3 Canal de dados ............................................. .................................................................... ...........................................18 ....................18 2.2.2.4 Função de controle H.245 ............................................ ................................................................... ...........................19 ....19 2.2.2.5 Negociação de capabilidade..................... capabilidade ............................................ ...............................................21 ........................21 2.2.2.6 Sinalização de canal lógico...................... lógico .............................................. ...............................................22 .......................22 2.2.2.7 Determinação de mestre-escravo ............................................ ............................................................22 ................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 ................24 2.2.2.10 Função de sinalização de chamada ............................................. .........................................................24 ............24 2.2.3. ................................................................... .............................................. ...............................25 ........25 Gateway ............................................ 2.2.3.1 Decomposição lógica de um gateway.....................................................26 2.2.3.2 Decomposição física de um gateway ......................................................27 Trunking e Access Gateways ..................................................................28 2.2.3.3 2.2.3.4 Exemplos de Utilização de Trunking e Access Gateways ......................30 2.2.4. ................................................................... .............................................. ...........................31 ....31 Gatekeeper ............................................ 2.2.5. Características de Conferência Multiponto......................................... Multiponto.............................................32 ....32 2.3. SINALIZAÇÃO DE CHAMADAS ........................................... .......................................................34 ............34 2.3.1. Endereçamento........................................................................................34 2.3.2. Canal RAS (Registro, Admissão e Estado) ........................................... ............................................35 .35 2.3.3. Canal de Sinalização de Chamada .............................................. ..........................................................36 ............36 2.3.4. Valor de Referência de Chamada ........................................... ...........................................................36 ................36 2.3.5. Identificação de Chamada..................... Chamada ............................................ .............................................. ...........................37 ....37 2.3.6. Identificação de Conferência e Objetivo de Conferência .......................37 .......................37 2.3.7. Capacidade de Chamada de Terminal ............................................ ....................................................37 ........37 2.3.8. Serviços de Identificação de Chamador.................................. Chamador..................................................38 ................38 2.4. PROCEDIMENTOS DE SINALIZAÇÃO DE CHAMADAS ..............38 2.4.1. Fase A – Call Setup ............................................. .................................................................... ...................................38 ............38 2.4.2. Fase B – Comunicação Inicial e Troca de Capabilidade ........................42 ........................42 2.4.3. Fase C – Estabelecimento de Comunicação Áudio Visual.................... Visual .....................43 .43 2.4.4. Fase D – Serviços de Chamadas ............................................. .............................................................43 ................43 2.4.5. Fase E – Finalização de Chamada .............................................. ..........................................................45 ............45 3. PROTOCOLO SIP (IETF)............................................................. (IETF).................................................................................... ........................46 .46 3.1. INTRODUÇÃO......................................................................................46 3.2. ESTRUTURA.........................................................................................47 3.3. DEFINIÇÕES .............................................. ..................................................................... ...........................................47 ....................47 3.4. MENSAGENS SIP .............................................. ..................................................................... ...................................50 ............50
6
3.4.1. Requisições Requi sições .............................................. ...................................................................... ...............................................50 .......................50 3.4.2. Respostas .............................................. ..................................................................... .............................................. ...........................51 ....51 3.5. COMPORTAMENTO GERAL DO USER AGENT ..............................51 3.5.1. Comportamento do UAC ............................................. .................................................................... ...........................52 ....52 3.5.2. Comportamento do UAS ............................................. .................................................................... ...........................53 ....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....................... CAPABILIDADE ...............................................56 ........................56 3.9. DIÁLOGOS............................................................................................57 3.10. SESSÃO..................................................................................................58 PROXY .............................................. 3.11. ..................................................................... .............................................. ...............................59 ........59 Stateful proxy ........................................... 3.11.1. .................................................................. .............................................. ........................59 .59 3.11.2. .................................................................... ...........................................61 ....................61 Stateless proxy ............................................. 3.12. TRANSAÇÕES ........................................... .................................................................. ...........................................61 ....................61 3.13. TRANSPORTE.......................................................................................62 3.14. CAMPOS DE CABEÇALHO ............................................ ................................................................63 ....................63 3.15. CÓDIGOS DE RESPOSTA ........................................... .................................................................. ........................65 .65 3.15.1. Respostas provisórias 1xx........................................ 1xx............................................................... ...............................66 ........66 3.15.2. Resposta de sucesso 2xx .............................................. ..................................................................... ...........................66 ....66 3.15.3. Respostas de redireção 3xx...................... 3xx ............................................. .............................................. ........................66 .66 3.15.4. Resposta de falha 4xx .............................................. ..................................................................... ...............................67 ........67 3.15.5. Resposta de falha de servidor 5xx .............................................. ..........................................................69 ............69 3.15.6. Respostas de falha global 6xx......................................... 6xx................................................................ ........................70 .70 3.16. USO DE AUTENTICAÇÃO HTTP....................................... HTTP.......................................................70 ................70 4. ANÁLISE COMPARATIVA COMPARATIVA ENTRE ENTRE H.323 E SIP ............................................ .............................................72 .72 4.1. COMPLEXIDADE.................................................................................72 4.2. EXTENSIBILIDADE E MODULARIDADE................................ MODULARIDADE........................................73 ........73 4.3. ESCALABILIDADE..............................................................................74 4.4. SERVIÇOS .............................................. ..................................................................... .............................................. ........................75 .75 4.5. SEGURANÇA........................................................................................75 5. CONCLUSÃO ............................................. .................................................................... .............................................. ...................................77 ............77 6. REFERÊNCIAS BIBLIOGRÁFICAS........................................ BIBLIOGRÁFICAS............................................................... ...........................79 ....79
7
LISTA DE TABELAS Tabela 1 - Tipos de terminal para determinação determinação mestre-escravo mestre-escravo H.245 (fonte: ITU-T) ITU-T) 23
8
LISTA DE FIGURAS Figura 1 – Escopo da recomendação H.323 (fonte: ITU-T) ........................................... ........................................... 15 Figura 2 – Exemplo de topologia com gateways (fonte: autor)...................... 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) ITU-T)..................... ............................................ ......................... 28 Figura 5 - Relacionamento entre gateways H.323, SCN e H.248 (fonte: (fonte: ITU-T)..... ITU-T) ......... ...... 29 Figura 6 - Relacionamento entre H.323 e H.248 (fonte: ITU-T).................................... 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)....................... ITU-T) ......................... 30 Figura 9 - Possíveis localizações de um MC ou MP (fonte: ITU-T)...................... ITU-T) .............................. ........ 33 Figura 10 - Call setup básico sem gatekeeper (fonte: ITU-T)........................................ ITU-T)........................................ 39 Figura 11 - Terminais registrados no mesmo gatekeeper , com sinalização direta (fonte: ITU-T)...................... ITU-T) ............................................. .............................................. .............................................. ......................... 39 Figura 12 - Terminais registrados no mesmo gatekeeper , com sinalização roteada (fonte: ITU-T)...................... ITU-T) ............................................. .............................................. .............................................. ......................... 40 Figura 13 - Somente terminal terminal chamador registrado, registrado, sinalização sinalização direta (fonte: ITU-T) ITU-T) . 40 Figura 14 - Somente terminal chamador registrado, sinalização roteada (fonte: ITUT) ............................................. .................................................................... .............................................. ........................................... .................... 41 Figura 15 - Chamador registrado no gatekeeper , sinalização sinalização direta (fonte: (fonte: ITU-T) ITU-T) ...... ...... 41 Figura 16 - Exemplo de requisição REGISTER REGISTER (fonte: IETF) ...................................... ...................................... 56 Figura 17 - Exemplo de requisição OPTIONS (fonte: IETF)......................................... IETF)......................................... 56 Figura 18 - Exemplo de resposta OPTIONS (fonte: IETF) IETF) ........................................... ............................................. 57 Figura 19 - Modelo de Proxy Stateful (fonte: IETF) .............................................. ...................................................... ........ 60 Figura 20 - Relacionamento de transações (fonte: IETF)............................................... IETF)............................................... 62
9
LISTA DE ABREVIATURAS E SIGLAS ACF ACK AOR APDU ARJ ARQ ASCII BCF BNF BRJ BRQ BRI CAS CCITT CID CIF CRFL CRV CT DoS DNS FAS GCC GW HTTP IANA ID IETF IMT IP IPX IRQ IRR ITU ISDN ISUP LAN MC MCU MEGACO MGC MG MIKEY MIME MMUSIC
Admission Confirmation Acknowledge Address Of Record Application Protocol Data Unit Admission Reject Admission Request American Standard Code for Information Interchange Bandwidth Change Confirmation Backus–Naur Form Bandwidth Change Reject Bandwidth Change Request Basic Rate Interface Channel Associated Signaling Commité Consultatif International de Telegraphique et Telephonique Conference Identifier Common Intermediate Format Carriage-Return Line-Feed Call Reference Value Client Transaction Denial Of Service Domain Name System Facility Associated Signaling Generic Conference Control Gateway Hypertext Transfer Protocol Internet Assigned Numbers Authority Identification Internet Engineering Task Force Inter-Machine Trunk Internet Protocol Internetwork Protocol Exchange Information Request Information Request Response International Telecommunication Union Integrated Services Digital Network ISDN User Part Local Area Network Multipoint Controller Multipoint Control Unit Media Gateway Control Media Gateway Controller Media Gateway Multimedia Internet KEYing Multipurpose Internet Mail Extensions Multiparty Multimedia Session Control Working Group IETF
10
MP NAT NFAS NNI PABX PGP PRI PSTN QCIF QoS QSIG RAS RFC RTCP RTP RTSP S/MIME SCM SCN SCTP SDP S-HTTP SIP SIPS SPX SRTP SS7 SSH SSL ST TCP TLS TSAP TU UA UAC UAS UDP URI URL WWW
Multipoint Processor Network Address Translation Non-Facility Associated Signaling Network-to-Network Interface Private Automatic Branch Exchange Pretty Good Privacy Primary Rate Interface Public Switched Telephone Network Quarter Common Intermediate Format Quality Of Service Signaling Between the Q Reference points Registration, Admission, Status Request For Comments Real Time Control Protocol Real Time Protocol Real Time Streaming Protocol Secure / Multipurpose Internet Mail Extensions Selected Communications Mode Switched Circuit Network Stream Control Transmission Protocol Session Description Protocol Secure Hypertext Transfer Protocol Session Initiation Protocol Session Initiation Protocol Secure Sequential Protocol Exchange Secure Real Time Transport Protocol Signaling System n. 7 Secure Shell Secure Sockets Layer Server Transaction Transport Control Protocol Transport Layer Security Transport layer Service Access Point Transaction User User Agent User Agent Client User Agent Server User Datagram Protocol Uniform Resource Identifier Uniform Resource Locator World Wide Web
11
1. INTRODUÇÃO
O H.323 (ITU-T) e o SIP (IETF) são atualmente os dois protocolos de sinalização mais utilizados em voz sobre IP. A rivalidade entre os dois é latente, os defensores de cada um são radicais quando se trata de comparações e há quem defenda ambos os protocolos. É difícil afirmar de forma definitiva qual deles é o melhor, o mais confiável, o mais robusto ou qual será o protocolo de sinalização mais utilizado daqui dez anos. Ou ainda se algum deles tende a se extinguir ou não. Ambos possuem características distintas e estão sendo muito usados. Enquanto a recomendação ITU-T é muito mais completa e, ao mesmo tempo, mais complexa, a RFC referente ao SIP, do IETF, de certa forma simplifica a maneira de se estabelecer uma chamada de voz sobre IP, mas acaba se tornando um tanto quanto minimalista, indo de encontro aos princípios do H.323. A primeira versão do H.323 de 1996 se definia como um “sistema de telefones e equipamentos visuais para redes locais que provêem qualidade de serviço não-garantida”. Com o avanço do protocolo e a demanda por novos serviços, esta denominação foi se alterando, chegando-se a versão atual (2006) como “sistemas de comunicação multimídia baseadas em pacotes” [1]. O SIP foi criado com o objetivo de ser um protocolo de Internet , com sinalização em texto claro, baseado no conhecido protocolo HTTP (camada de aplicação). O SIP surgiu em meados de 1996 como um internet draft do IETF, com o primeiro RFC sendo publicado em 1999. A versão mais atual publicada é a RFC 3261 do ano de 2002. 1.1. ITU-T E IETF
O ITU-T (o último “T” faz referência ao setor de padronização da instituição) é uma entidade internacional de origem européia, anteriormente conhecida como CCITT, de reconhecido respaldo perante a comunidade envolvida com telecomunicações. Além disso, é reconhecida como a agência oficial das Nações Unidas especializada em telecomunicações [1]. Já o IETF é um consórcio de caráter internacional que surgiu em 1986, originalmente vinculado ao governo dos Estados Unidos. Com o 12
crescimento exponencial da Internet , diversos indivíduos e instituições de outros países se envolveram com a entidade em prol de um objetivo comum, que é o desenvolvimento da arquitetura da Internet e sua correta operação [2], o que tornou a entidade mais internacional do que norte-americana. 1.2. OBJETIVO
O objetivo deste trabalho é explanar de forma detalhada e objetiva as características dos protocolos H.323 e SIP, assim como realizar uma análise comparativa entre os dois protocolos. 1.3. ESTRUTURA DO TRABALHO
Nos capítulos dois e três o trabalho abordará as características individuais de cada protocolo, fornecendo uma visão geral de funcionamento e detalhes de sinalização. No capítulo quatro a abordagem é comparativa, analisando-se as vantagens e desvantagens que cada protocolo tem em relação ao outro.
13
2. PROTOCOLO H.323 (ITU-T)
2.1. INTRODUÇÃO
O padrão H.323 é parte da família de recomendações que pertence à série H da ITUT, que trata de sistemas audiovisuais e multimídia. Esta recomendação tem por objetivo especificar sistemas de comunicação multimídia em redes baseadas em pacotes e que não provêem qualidade de serviço garantida, estabelecendo padrões para codificação e decodificação de fluxos de dados de áudio e vídeo, garantindo que produtos baseados no padrão H.323 de um fabricante sejam operacionais quando se comunicando com produtos H.323 de outros fabricantes [3]. A recomendação H.323 especifica o uso de áudio, vídeo e dados em comunicações multimídia, sendo que apenas o suporte à mídia de áudio é obrigatório. Mesmo sendo somente o áudio obrigatório, cada mídia (áudio, vídeo e/ou dados), quando utilizada, deve seguir as especificações do padrão. Pode-se ter uma variedade de formas de comunicação,
envolvendo
áudio
apenas
(telefonia
IP),
áudio
e
vídeo
(videoconferência), áudio e dados e, por fim, áudio, vídeo e dados. As informações contidas neste capítulo sobre H.323, quando não citado outro autor, são baseadas em [1]. 2.2. ELEMENTOS DO H.323
2.2.1. Fluxos de Informação
Os componentes de um terminal H.323 se comunicam através de fluxos de informação, que podem ser classificados como: •
Áudio: contêm uma fala digitalizada e codificada, acompanhada de uma sinalização de controle de áudio.
14
•
Vídeo: contêm vídeo animado digitalizado e codificado, sendo transmitido a uma taxa não maior que a selecionada, resultado da troca de informações de capabilidade.
•
Dados: inclui figuras, fax, documentos, arquivos diversos de computador e outros fluxos de dados.
•
Sinais de controle de comunicação: passam dados de controle entre elementos “remotos” e são usados para negociação de capabilidade, abertura e fechamento de canais lógicos, controles de modo e outras funções que fazem parte do controle de comunicação.
•
Sinais de controle de chamada: utilizados para estabelecimento, desconexão e outras funções de controle de chamada.
2.2.2. Terminal
Figura 1 – Escopo da recomendação H.323 (fonte: ITU-T) IT U-T)
Um terminal é toda entidade capaz de se comunicar através do protocolo H.323 e que se utiliza do escopo mostrado na figura 1. Todo terminal H.323 é obrigado a possuir
15
uma unidade de controle de sistema, uma camada H.225.0, uma interface de rede e uma unidade de codec de áudio. Opcionalmente o terminal pode possuir uma unidade de codec de vídeo e aplicações de dados de usuário. Na interface de rede (e na rede conectada a ela é claro), é imprescindível a disponibilidade dos seguintes serviços: •
Serviço fim a fim confiável (TCP, SPX, etc.): obrigatório para o canal de controle H.245, canais de dados, canal de sinalização de chamada.
•
Serviço fim a fim não-confiável (UDP, IPX, etc.): obrigatório para os canais de áudio, canais de vídeo e o canal RAS.
Estes serviços poderão ser disponibilizados na forma de transmissão simplex ou duplex, unicast ou multicast ,
dependendo da aplicação, das capabilidades do terminal
e da configuração da rede. 2.2.2.1 Características de vídeo
Uma vez que algum terminal possua capabilidade de vídeo (que é opcional), é mandatório que o mesmo seja capaz de codificar e decodificar vídeo de acordo com a recomendação H.261 QCIF, que é o codec de vídeo com taxa de 30 quadros por segundo, sendo que cada um destes quadros possui as dimensões de 144 linhas e 176 pixels por
linha. Este formato, como o próprio nome sugere, equivale a um quarto da
resolução total do formato CIF [4]. Opcionalmente, o terminal pode ter suporte a outros modos do H.261 (CIF, por exemplo) e também outros codec’s como H.263 ou H.264, que possuem algoritmos aperfeiçoados e desempenho superior. Outros codec’s de vídeo e formatos de imagem podem ser utilizados através de negociação H.245, sendo que mais de um canal de vídeo pode ser transmitido e/ou recebido ao mesmo tempo (por exemplo, em uma sessão de videoconferência multiponto), quando negociado pelo canal de controle H.245. O codificador poderá somente transmitir características de vídeo que foram estabelecidas com o
16
decodificador, durante a negociação de capabilidade. Além disso, os terminais H.323 têm a opção de operação em diferentes taxas de bit ou taxas de quadros. Por exemplo, um terminal pode transmitir QCIF enquanto recebe CIF. Quando um canal lógico de vídeo é aberto, o modo de operação a ser utilizado é sinalizado
do
transmissor
“openLogicalChannel”.
ao
receptor
através
da
mensagem
H.245
É no cabeçalho dentro do canal lógico de vídeo que se
encontra indicado o modo utilizado naquele instante para cada imagem, dentro da capabilidade do decodificador. 2.2.2.2 Características de áudio
É obrigatório que um terminal H.323 possua o codec de áudio G.711 e seja capaz de transmitir e receber nos modos A-law e µ-law. Opcionalmente outros codec's podem ser utilizados sem problemas, uma vez que sejam sinalizados pelo canal H.245. Isso ocorre durante a troca de capabilidade entre as entidades envolvidas (codificador e decodificador). Similarmente à característica de vídeo, o áudio tem a possibilidade de operação assimétrica, ou seja, um terminal pode, por exemplo, enviar áudio em G.711 e receber em G.723, desde que codificador e decodificador tenham capabilidade de ambos os codec's . Pacotes de áudio devem ser entregues periodicamente a camada de transporte em um intervalo determinado pela recomendação ITU-T do codec de áudio em uso. A entrega de cada pacote deve ocorrer em não menos que 5ms, depois de um múltiplo inteiro do intervalo de quadro de áudio, mensurado a partir da entrega do primeiro quadro de áudio (audio delay jitter ). ). Codificadores capazes de limitar seu tempo de audio
delay
jitter
devem
sinalizá-lo
utilizando-se
o
parâmetro
H.245
“maximumDelayJitter ”, ”, da estrutura “h2250Capability” contida dentro da mensagem “terminal capability set message ”. Assim os receptores podem opcionalmente reduzir o buffer de jitter delay. Para definir corretamente o tamanho do buffer de jitter , os terminais H.323 devem
17
transmitir a mensagem “h2250MaximumSkewIndication” para indicar a diferença máxima de tempo entre os sinais de áudio e vídeo, para serem entregues a rede de transporte. Esta mensagem deverá ser enviada para cada par de canais lógicos de áudio e vídeo associados. Esse procedimento não é necessário em conexões exclusivas de áudio. Em chamadas de conferência, os terminais H.323 devem ser capazes de realizar recepção de mais de um canal de áudio, mixando todos os canais que estão sendo recebidos ao mesmo tempo. O terminal deve usar capabilidade simultânea do H.245 para indicar quantos fluxos de áudio será capaz de decodificar ao mesmo tempo. Essa capabilidade simultânea não pode limitar o número de fluxos de áudio que estão sendo transmitidos em multicast em uma conferência. 2.2.2.3 Canal de dados
Um ou mais canais de dados são opcionais para um terminal, podendo ser unidirecional ou bidirecional. A recomendação T.120 é a base padrão de interoperabilidade entre terminais H.323 com outros tipos de terminais como H.323, H.324, H.320 ou H.310. Esta recomendação descreve uma série de protocolos aplicativos e de comunicação que provêem suporte para comunicação de dados multiponto em tempo real. Aplicativos como Microsoft Netmeeting ou Lotus Sametime se
utilizam desta recomendação [5].
Uma conexão T.120 é estabelecida durante uma chamada H.323, sendo uma parte essencial desta chamada. Depois da troca de capabilidades, um canal lógico bidirecional deve ser aberto para a conexão T.120, através da mensagem “openLogicalChannel”.
Se o terminal que está sendo convidado, aceitar a abertura
de canal, então este enviará a mensagem “openLogicalChannelAck”. Nesta mensagem, o terminal convidado deve incluir seu endereço de transporte, mesmo esperando que o terminal chamador inicie a chamada. Em todos os casos, o endereço de transporte deve estar presente no parâmetro “separateStack” e deve permanecer válido pelo tempo da duração da conexão do canal lógico T.120.
18
Em ambas as mensagens “openLogicalChannel” e “openLogicalChannelAck”, a alternativa “t120SetupProcedure” , da estrutura “NetworkAccessParameters” indica à parte oposta (chamador ou recebedor) como a chamada será estabelecida. A opção “originateCall”
diz ao emissor da mensagem para iniciar a chamada. Já a opção
“waitForCall” significa que o emissor da mensagem irá receber a chamada.
No caso de conferência, que inclui áudio, vídeo e dados T.120, quando um terminal tiver a intenção de iniciar uma, o canal de controle H.245 precisa ser estabelecido antes que a conexão T.120 seja realizada. Isso se aplica a criação de conferência, entrada em conferência estabelecida e convite/ações de um MC de uma conferência. Os procedimentos de call setup devem ser utilizados para se estabelecer o MC ativo (se existir), antes da conexão T.120. Usando-se uma requisição GCC de entrada em conferência estabelecida, para se estabelecer uma conexão T.120, os terminais necessitam saber o nome da conferência T.120. Se um nome para a conferência H.323 já existe (conferenceAlias), o mesmo nome pode ser usado como o nome de conferência T.120. Da mesma forma, o CID H.323 poderá ser utilizado como o nome de conferência T.120 numérico. Cada octeto do CID H.323 é convertido em uma séria de três caracteres ASCII, que representa o valor decimal do octeto. O encerramento de uma conferência T.120 não implica o encerramento de uma chamada H.323. Quando o fluxo de dados T.120 é encerrado, a chamada H.323 continua ativa. Mas quando o contrário ocorre, ou seja, a chamada H.323 é encerrada, o fluxo de dados automaticamente termina também. 2.2.2.4 Função de controle H.245
A função de controle utiliza o canal H.245 para enviar mensagens de controle fim a fim, gerenciando a operação de entidades H.323, incluindo negociação de capabilidade, abertura e fechamento de canais lógicos, requisições de preferência de modo, mensagens de controle de fluxo e comandos genéricos.
19
Esta sinalização pode ser estabelecida entre: •
Dois terminais;
•
Um terminal e um MC;
•
Um terminal e um gatekeeper
Para cada chamada H.323 que um terminal estabeleça, haverá somente um canal lógico de controle H.245 aberto. É importante salientar que terminais, MCU’s, gateways ou gatekeepers podem (e devem) suportar mais de uma chamada ao mesmo
tempo e, conseqüentemente, um canal de controle para cada uma destas chamadas. O canal de controle H.245 deve ser transportando pelo canal lógico zero. A recomendação H.245 especifica um número de entidades de protocolo que suportam comunicação de sinalização de terminal a terminal. Uma entidade de protocolo é especificada pela sua sintaxe (mensagens), semânticas e um conjunto de procedimentos que especifica a troca de mensagens e a interação com o usuário. Os terminais H.323 devem suportar as seguintes entidades de protocolo: •
Determinação de mestre/escravo.
•
Negociação de capabilidade.
•
Sinalização de canal lógico.
•
Sinalização bidirecional de canal lógico.
•
Fechamento de canal lógico de sinalização.
•
Requisição de modo.
•
Determinação de Round Trip Delay .
•
Sinalização de loop de manutenção.
Existem quatro categorias de mensagens H.245: •
Requisição (request ). ).
•
Resposta (response ).
•
Comando (command ). ).
20
•
Indicação (indication).
Mensagens de requisição e resposta são utilizadas por entidades de protocolo. As requisições exigem uma imediata ação do receptor, que é a resposta. Mensagens de comando exigem também uma ação do receptor, mas não precisam de resposta. Já as mensagens de indicação são somente informativas, não requerendo nenhuma ação do receptor. 2.2.2.5 Negociação de capabilidade
A negociação de capabilidade é a troca de informações entre terminais, quanto às suas características de transmissão e recepção, realizada antes de uma conexão ser estabelecida. As capabilidades de recepção descrevem as habilidades de um terminal receber e processar fluxos de informação. Neste caso os transmissores devem limitar o conteúdo da informação enviada, para os padrões que o receptor indicou na negociação de capabilidade. Se o terminal omitir informações de capabilidade de recepção, então este terminal não é apto a receber fluxos de informação, somente transmitir. As capabilidades de transmissão descrevem as habilidades de um terminal para transmitir fluxos de informação. Estas capabilidades servem para os transmissores oferecerem aos receptores, alternativas de possíveis modos de operação, para desta forma, o receptor requisitar o modo que ele prefere utilizar. Em caso de omissão de capabilidade de transmissão, isso indica que o terminal não está oferecendo uma alternativa de modos preferenciais ao receptor (mas ele poderá ainda assim transmitir qualquer informação que esteja dentro das capabilidades do receptor). As capabilidades de transmissão e recepção descrevem as habilidades de um terminal para receber e transmitir fluxos de informação, quando estas capabilidades não são independentes e são requeridas a operarem em ambas as direções.
21
2.2.2.6 Sinalização de canal lógico
Cada canal lógico carrega informação de um transmissor para um ou mais receptores e é identificado por um número de canal lógico que é único para cada direção de transmissão. Canais lógicos são abertos e fechados usando-se as mensagens “openLogicaChannel”
e “closeLogicalChannel”, mais os procedimentos da
recomendação H.245. Quando um canal lógico é aberto, a mensagem “openLogicalChannel” descreve totalmente o conteúdo do canal lógico, incluindo tipo de mídia, algoritmo em uso, quaisquer opções e toda informação requerida pelo receptor para interpretar o conteúdo do canal lógico. Canais lógicos podem ser fechados quando não forem mais necessários. A abertura de canal lógico deve permanecer inativa, caso a fonte de informação não tenha nada a enviar. Quando o terminal iniciador envia a mensagem “openLogicalChannel” para iniciar o processo de abertura de canal lógico, e se o canal lógico for para transporte de mídia RTP
(áudio
ou
vídeo),
“mediaControlChannel”
a
mensagem
deve
incluir
o
parâmetro
contendo o endereço de transporte para o canal reverso
RTCP. O terminal respondedor, retornando a mensagem “openLogicalChannelAck”, deve conter o parâmetro “mediaChannel”, que contêm o endereço de transporte RTP para o canal de mídia. A mensagem deve conter também o parâmetro “mediaControlChannel”,
que vai indicar o endereço de transporte do canal RTCP.
Tipos de mídia que não utilizam RTP/RTCP (como dados T.120), devem omitir o parâmetro “mediaControlChannel”. 2.2.2.7 Determinação de mestre-escravo
Os procedimentos H.245 de determinação mestre-escravo são utilizados para resolver conflitos entre dois terminais, podendo ambos estar tentando ser um MC 22
(controlador multiponto) de uma conferência ou entre dois terminais tentando abrir um canal lógico bidirecional. Neste procedimento, dois terminais trocam números aleatórios em uma mensagem H.245 “masterSlaveDetermination”, para determinar quem é mestre e quem é escravo. Os terminais devem configurar o “terminalType” com os valores dados na tabela 13 e configurar o “statusDeterminationNumber” para um número aleatório, compreendido entre 0 e 224-1. Apenas um número aleatório pode ser adquirido pelo terminal para cada ligação e um MC ativo em conferência deve ter valor 240 para “terminalType”.
Entidade H.323
“terminalType”
Característica
Terminal
Gateway
Gatekeeper
MCU
Entidade sem MC
50
60
-
-
Entidade com MC, mas sem MP
70
80
120
160
Entidade com MC, com dados MP
-
90
130
170
Entidade com MC, com dados e áudio MP
-
100
140
180
Entidade com MC, com dados, áudio e vídeo MP
-
110
150
190
Tabela 1 - Tipos de terminal para determinação mestre-escravo H.245 (fonte: ITU-T)
2.2.2.8 Fluxo multiplexado de transmissão sobre um canal lógico simples
Múltiplos fluxos de mídia podem ser multiplexados sobre um único canal lógico, utilizando-se os protocolos H.222 ou H.223. Multiplexando um fluxo de mídia, um terminal se aproveita de alguns benefícios como a utilização mais eficiente de banda, sincronização precisa de mídia e baixo atraso em transmissões multimídia. Existem duas maneiras de se controlar um fluxo multiplexado. Uma delas é através de mensagens H.245 encapsuladas nos pacotes RTP. Neste caso, o terminal primeiramente abre um canal lógico para a transmissão de mídia multiplexada, como uma transmissão RTP qualquer. Depois de estabelecida, o controle da multiplexação de fluxos é realizado pelas mensagens H.245 encapsuladas nos pacotes RTP.
23
A outra forma de se controlar fluxos multiplexados é através de mensagens H.245 enviadas de maneira normal, como em um fluxo não multiplexado. A diferença é que na abertura de canal lógico de sinalização, este possuirá parâmetros relativos à mídia multiplexada.
2.2.2.9 Sinalização RAS
A função RAS de sinalização utiliza-se de mensagens H.225.0 para realizar registro, admissões, alteração de largura de banda, estado e procedimentos de desconexão entre terminais e gatekeepers. O canal RAS de sinalização é independente do canal de sinalização e do canal de controle H.245. O procedimento de abertura de canal lógico H.245 não são utilizados para se estabelecer um canal de sinalização RAS. Em cenários onde não há a presença de um gatekeeper , a sinalização RAS não é utilizada. Já em cenários onde existe um gatekeeper (uma zona), o canal de sinalização RAS é utilizado entre o terminal e um gatekeeper e é aberto prioritariamente a outros canais de sinalização entre terminais H.323. 2.2.2.10 Função de sinalização de chamada
A função de sinalização de chamada utiliza-se de sinalização H.225.0 para estabelecer uma conexão entre dois terminais H.323. Esta função é independente do canal RAS e do canal de controle H.245, sendo que os procedimentos de abertura de canal lógico não são utilizados para estabelecer o canal de sinalização de chamada. O canal de sinalização de chamada é sempre aberto antes do estabelecimento do canal lógico H.245 e qualquer outro canal lógico entre entidades H.323. Este canal é aberto entre um gatekeeper e um terminal H.323 ou, quando não existir um gatekeeper , entre dois terminais H.323.
24
2.2.3. Gateway
O princípio dos gateways é trabalhar como uma interface de tradução entre uma rede de dados (IP, por exemplo) e uma rede de circuito comutado (sistema telefônico convencional), provendo tradução apropriada entre formatos de transmissão diferentes. O gateway pode ser considerado um terminal H.323 e também um terminal da rede de circuito comutado. Gatekeepers não precisam se preocupar se um terminal é um gateway ou
não, pois no momento do registro do gateway ou terminal simples, o tipo
de terminal é indicado, dizendo se é ou não um gateway sendo registrado em um gatekeeper .
A função de conversão dos gateways provê a conversão necessária de formatos de transmissão, controles, áudio, vídeo e/ou fluxo de dados entre diferentes terminais de diferentes protocolos. De acordo com a recomendação H.323, o mínimo que o gateway deve
prover é uma função de conversão para formatos de transmissão, sinais
e procedimentos de call setup, e procedimentos e sinais de controle de comunicação.
Terminal H.323
Terminal H.323
Gateway (funções de conversão)
Gateway (funções de conversão)
Terminal da SCN
Terminal da SCN
Figura 2 – Exemplo de topologia com gateways (fonte: autor)
25
2.2.3.1 Decomposição lógica de um gateway
Esta seção identifica um grupo de interfaces e funções, a ser utilizado para decompor gateways
H.323. Este grupo endereça cada interface e seu protocolo resultante, mas
certas implementações de gateways devem escolher em agrupar dois ou mais componentes funcionais dentro de um único dispositivo físico. Por esta razão, interfaces podem prover a capabilidade de transparentemente transportar outros protocolos.
Figura 3 - Arquitetura funcional de um gateway decomposto logicamente (fonte: ITU-T)
Na figura 3, que representa um gateway decomposto, a interface “A” representa o protocolo de controle de dispositivo definido pelo H.248.1, que é utilizado para criar, modificar e terminar conexões de Gateway media. A interface “B” representa os componentes de protocolo H.225.0 e H.245 que ativam as interfaces de sinalização, no lado IP do gateway. A interface “C” descreve a função de controle de chamada do tipo ISDN, entre FAS SCN e a lógica de controle de gateway. Já na interface “D”, podemos observar o protocolo que converte a sinalização NFAS SCN para o
26
controlador. Esta decomposição provê a flexibilidade de conservar pontos de código SS7 e permite que o comutador SS7 sirva múltiplos Gateway Controllers decompostos. A decomposição lógica de um gateway facilita o agrupamento de todos estes elementos dentro de dispositivos físicos, visando a implementação de todas as interfaces para produzir um equipamento de alta escalabilidade e padronização. 2.2.3.2 Decomposição física de um gateway
Um gateway basicamente se divide em duas partes: o Media Gateway Controller (MGC) e o Media Gateway (MG). As funções do MGC são: •
Manipular mensagens RAS H.225.0 com um gatekeeper externo.
•
Opcionalmente manipular a interface de sinalização SS7.
•
Opcionalmente manipular a interface de sinalização H.323.
•
Responsável pela alocação e administração de recursos de alto-nível (canceladores de eco, por exemplo).
As funções do MG são: •
Terminação da interface de rede IP.
•
Terminação da extensão de rede SCN.
•
Manipular sinalização H.323 em algumas decomposições físicas.
•
Manipular sinalização FAS SCN em algumas decomposições físicas.
•
Responsável pela alocação e administração de recursos de baixo-nível, assim como manipulações de hardware requeridas para comutar e processar fluxos de mídia dentro do Media Gateway .
Na figura 4 está ilustrado um exemplo de gateway decomposto fisicamente. 27
Figura 4 - Decomposição de gateway SS7 (fonte: ITU-T)
2.2.3.3 Trunking e Access Gateways
Os termos trunking e access gateways são utilizados tanto no H.323 como no H.248, assim como fazem parte da terminologia utilizada em comutação por circuito, onde são aplicadas para funções tandem e de comutador de acesso. Na SCN, um comutador tandem ou trunking conecta redes usando um protocolo NNI, como o SS7/ISUP ou CAS NNI. Já um comutador de acesso refere-se às centrais comutadoras que possuem conexões de usuários, utilizando-se BRI/PRI e é também conectado a redes maiores, via protocolo NNI. Um comutador misto possui as duas funções. No H.323, trunking gateways são entidades com uma verdadeira função tandem, sendo que a transparência de protocolos convertidos é essencial, ou seja, se por uma das interfaces o protocolo utilizado é o QSIG, este deve ser “invisível” a outro trunking gateway,
por exemplo. Esta transparência é possível devido ao tunelamento
baseado na negociação de protocolo H.225.0 e Anexo M do mesmo. A figura abaixo exemplifica bem esta questão da transparência.
28
Figura 5 - Relacionamento entre gateways H.323, SCN e H.248 (fonte: ITU-T) Trunking
e access gateways são termos também utilizados na recomendação H.248.
O trunking gateway é aquele que a sinalização é conectada diretamente no MGC, ou seja, é um ISUP. Entretanto, analisando-se da perspectiva decomposta do H.323, o termo ganha variações. Um trunking gateway é aquele que a sinalização chega no MG e então é passada via H.248 para o MGC.
Figura 6 - Relacionamento entre H.323 e H.248 (fonte: ITU-T)
29
2.2.3.4 Exemplos de Utilização de Trunking e Access Gateways
Na figura 11 observa-se um exemplo de chamada roteada através da rede comutada por pacotes (IP, por exemplo), entre dois provedores de serviço. A interface “A” neste caso é utilizada para controlar os Media Gateways, a interface “X” é a sinalização entre MGC’s (H.225) e o Media Flow é o fluxo de voz sobre uma rede comutada por pacotes entre os dois gateways.
Figura 7 - Trunking Gateways decompostos entre dois provedores de serviço (fonte: ITU-T)
Na figura 12 é exemplificado um Access Gateway que conecta um PABX corporativo através de um enlace CAS, aos serviços do provedor, que tem o gateway conectado a uma rede de comutação por circuito SS7. Neste exemplo “X” é a sinalização H.225.0 entre o Access Gateway e o gateway composto conectado ao PABX, e “A” é a sinalização de controle do MG.
Figura 8 - Access Gateway de um provedor de serviços (fonte: ITU-T)
30
2.2.4. Gatekeeper
O gatekeeper é uma entidade (opcional) em um sistema H.323 que provê serviços de controle de chamadas para os terminais H.323. Logicamente, o gatekeeper se encontra separado dos terminais, mas fisicamente podem existir implementações em que ele possa coexistir com um terminal, MCU, gateway, MC ou algum outro dispositivo que não seja H.323. A área (lógica) de alcance em que um gatekeeper atua e controla terminais é chamada zona. Em uma zona é permitido existir somente um gatekeeper , embora múltiplos dispositivos físicos possam oferecer os serviços de gatekeeper em uma única zona. Estes múltiplos dispositivos físicos, adicionais em uma zona, são chamados de gatekeepers alternativos. Como o próprio nome sugere, eles são gatekeepers
com função de redundância.
Os seguintes serviços são obrigatórios estarem presentes em um gatekeeper : •
Tradução de endereço: O gatekeeper deverá traduzir o endereço alias para o endereço de transporte. Isso é realizado utilizando-se uma tabela de tradução que é atualizada através das mensagens de registro (assunto abordado no capítulo referente à sinalização).
•
Controle de admissão: O gatekeeper deve autorizar acesso à rede utilizandose de mensagens H.225.0 ARQ/ACF/ARJ. A decisão de autorização se baseia em autorização de chamada, largura de banda ou algum outro critério definido pelo desenvolvedor.
•
Controle de largura de banda: O gatekeeper deve ter suporte a mensagens BRQ/BRJ/BCF, que é baseado na administração de largura de banda.
•
Administração de zona: O gatekeeper deve prover as funções acima citadas para terminais, MCU’s e gateways que se registraram nele.
Existem também outros serviços que podem ser implementados em gatekeepers, mas não obrigatórios estarem presentes de acordo com a recomendação H.323:
31
•
Sinalização de Controle de Chamada: O gatekeeper pode escolher a completar a sinalização de chamada com os terminais e pode processar a sinalização de chamada propriamente dita. De modo alternativo, o gatekeeper pode direcionar os terminais a conectar o canal de sinalização de chamada diretamente entre eles, fazendo com que o gatekeeper não precise realizar a sinalização de controle de chamada H.225.
•
Autorização de chamada: Através do uso da sinalização H.225, o gatekeeper pode rejeitar chamadas de um terminal em virtude de falha de autorização. As razões para rejeição podem incluir acesso restrito para/de terminais particulares ou gateways, e acesso restrito durante certos períodos de tempo.
•
Administração de largura de banda: Controle do número de terminais H.323 permitidos a acessar simultaneamente a rede. Através da sinalização H.225.0 o gatekeeper pode rejeitar chamadas de um terminal devido a limitações de largura de banda. Isso ocorre quando o gatekeeper determina que não há largura de banda suficiente para suportar uma ligação.
•
Administração de chamadas: O gatekeeper pode manter uma lista de chamadas em curso, pois esta informação pode ser necessária para indicar se um terminal está ocupado e também para prover informação pertinente à administração de largura de banda disponível.
•
Modificação de endereço de alias: O gatekeeper pode retornar um endereço de alias modificado. Se o gatekeeper retorna um endereço de alias em um ACF, o terminal deverá utilizar o endereço de alias para estabelecer a conexão.
2.2.5. Características de Conferência Multiponto
Conferência multiponto é um tipo de chamada onde estão envolvidos três ou mais terminais. Para este tipo de chamada ocorrer, são necessárias três entidades: MC, MCU e MP (não obrigadas a estarem todas na mesma chamada). O controlador multiponto (MC) provê funções de controle para suporte a conferência, entre três ou mais terminais em uma conferência multiponto. O
32
controlador multiponto deve negociar e administrar as capabilidades que cada terminal possui e que pode utilizar em uma conferência. Desta forma o MC determina o SCM (modo de comunicações selecionado) para a conferência, que deverá ser comum a todos os terminais envolvidos na conferência. Na inicialização de uma conferência multiponto, um terminal se tornará conectado a um MC em seu canal de controle H.245. Esta conexão pode ocorrer: •
Via uma conexão explícita com o MCU.
•
Via uma conexão implícita com o MC dentro de um gatekeeper.
•
Via uma conexão implícita com o MC dentro de outro terminal ou gateway na conferência multiponto.
•
Via uma conexão implícita por um gatekeeper até um MCU.
A escolha do modo de conferência (centralizada ou descentralizada) ocorre depois da conexão com o MC, utilizando-se sinalização H.245. A escolha do modo de conferência pode ser limitada pelas capabilidades dos terminais envolvidos ou pelo próprio MC. Um MC pode estar localizado dentro de um terminal, gatekeeper , gateway ou MCU, conforme figura a seguir.
Figura 9 - Possíveis localizações de um MC ou MP (fonte: ITU-T)
O MP (processador multiponto) é responsável por receber áudio, vídeo ou fluxos de
33
dados dos terminais envolvidos em uma conferência centralizada ou híbrida. O MP processa estes fluxos de mídia e retorna-os aos terminais. O MCU é um terminal que provê suporte para conferências multiponto. A estrutura do MCU é formada por um MC e nenhum ou mais MP’s.
2.3. SINALIZAÇÃO DE CHAMADAS
Sinalização de chamadas são as mensagens e procedimentos utilizados para estabelecimento de chamadas, requisição de alteração na largura de banda de uma chamada, requisição de informação de estado dos terminais em uma chamada e desconexão de chamada. A sinalização de chamadas utiliza-se de mensagens H.225. 2.3.1. Endereçamento
É mandatório que o terminal possua pelo menos um endereço de rede (IP, por exemplo), que vai identificar o mesmo na rede onde está localizado. Para cada endereço de rede, cada terminal H.323 pode ter vários identificadores TSAP, possibilitando a multiplexação de vários canais, compartilhando o mesmo endereço de rede. Terminais possuem um identificador TSAP conhecido e definido: o identificador TSAP do canal de sinalização de chamada. O mesmo ocorre com os gatekeepers , que possuem o identificador TSAP do canal RAS. Os gatekeepers possuem também um endereço multicast definido: o Discovery Multicast Address. Para o canal de controle H.245, canais de áudio, canais de vídeo e canais de dados, os terminais e demais entidades H.323 devem utilizar-se de identificadores TSAP dinâmicos. O mesmo acontece para os canais de sinalização de chamada, onde os gatekeepers devem se utilizar de identificadores TSAP dinâmicos também. Outro tipo de endereçamento utilizado é o alias. Um terminal pode ter um ou mais 34
alias
associados a ele. O alias representa o terminal propriamente dito ou
conferências que o terminal está hospedando no momento, e é uma forma alternativa de identificar um terminal. A representação de alias inclui dialledDigits, partyNumber e
H.323 ID (nomes alfanuméricos ou parecidos com endereço de
correio eletrônico). Quando um gatekeeper não está presente em um determinado sistema, o terminal chamador deve endereçar a chamada diretamente, utilizando o endereço de transporte do canal de sinalização de chamada do terminal chamado. E quando existe um gatekeeper no
sistema, o terminal chamador pode escolher entre endereçar o terminal
chamado pelo endereço de transporte, do canal de sinalização de chamada ou simplesmente pelo alias, que é posteriormente traduzido para o endereço de transporte. Uma das maneiras de endereçamento utilizadas de alias é através do ID de URL, que utiliza esquemas no padrão URL. 2.3.2. Canal RAS (Registro, Admissão e Estado)
O canal RAS é utilizado para transportar mensagens utilizadas no processo de descoberta de gatekeeper e processos de registro de terminais, que associam os alias de cada terminal aos respectivos endereços de transporte do canal de sinalização de chamada. Todas as mensagens do canal RAS são transmitidas em pacotes UDP, ou seja, não orientado a conexão. Tipicamente, equipamentos que realizam este tipo de sinalização adotam as portas 1719 (unicast ) e 1718 (multicast ) como padrão. Na descoberta de gatekeeper , o terminal envia mensagens multicast de descoberta de servidor, perguntando “quem é meu gatekeeper ?” ?” (mensagem de Gatekeeper Request )
e os servidores habilitados respondem com uma mensagem “eu posso ser
seu gatekeeper ” (mensagem de Gatekeeper Confirmation), que contêm o endereço de transporte do canal RAS do Gatekeeper . O terminal então escolhe o servidor em que deseja se registrar. Em caso de rejeição, a mensagem Gatekeeper Reject é enviada pelo gatekeeper ao terminal.
35
Neste momento, ao se registrar em um servidor, o terminal se junta à uma “Zona” e informa ao gatekeeper seu endereço de transporte e alias. Assim, quando outros terminais desejarem iniciar uma chamada, todos saberão a localização deste terminal registrado. 2.3.3. Canal de Sinalização de Chamada
O canal de sinalização de chamada é utilizado para transporte de mensagens de controle de chamada H.225.0, em um canal orientado à conexões. Em redes onde não há a presença de um gatekeeper os terminais trocam mensagens de sinalização de chamada diretamente uns com os outros. Em redes com a presença de um gatekeeper ,
as mensagens iniciais dos terminais são trocadas com o gatekeeper ,
utilizando-se o endereço de transporte do canal RAS. Enquanto as mensagens iniciais de admissão são trocadas, o gatekeeper indica em mensagens ACF se o terminal deve enviar as mensagens de sinalização diretamente ao outro terminal ou se elas devem ser intermediadas pelo próprio gatekeeper . Múltiplas chamadas simultâneas podem ser sinalizadas pelo mesmo canal de sinalização de chamadas. Isso pode ser feito através do valor de referência de chamada, que associará uma mensagem de sinalização de chamada a uma chamada. 2.3.4. Valor de Referência de Chamada Toda chamada deve conter um CRV (Call Reference Value ) ou valor de referência de chamada, um para o canal RAS e outro independente para o canal de sinalização de chamada. O CRV deve estar presente nas mensagens trocadas entre duas entidades (terminal-terminal ou terminal-gatekeeper ) relacionadas à mesma chamada. Quando um terminal convida uma terceira entidade a participar da mesma conferência, este canal de sinalização deve conter um novo CRV.
36
2.3.5. Identificação de Chamada
O Call ID ou identificação de chamada, ao contrário do CRV, não altera seu valor durante uma chamada. O Call ID é um valor, diferente de zero, criado pelo terminal que iniciou a chamada. Ele identifica a chamada com as mensagens associadas a ela. É utilizado para associar todos os canais RAS e de sinalização de chamadas relacionadas à mesma chamada.
2.3.6. Identificação de Conferência e Objetivo de Conferência
O CID (Conference ID ) é um valor diferente de zero criado pelo terminal chamador e passado em várias mensagens H.225.0. O CID identifica qual a conferência na qual as mensagens estão envolvidas. Assim, todas as mensagens pertencentes à mesma conferência possuirão o mesmo CID. O parâmetro ConferenceGoal ou Objetivo de Conferência indica a intenção da chamada. São elas: •
•
•
create: Para criar uma nova conferência. join: Para se juntar a uma conferência em andamento. invite:
Convida um novo terminal a se juntar a uma conferência em
andamento. •
capability-negotiation:
negocias as capabilidades para uma conferência
H.332 posterior. •
callIndependentSupplementaryService:
transporte de serviços suplementares
APDUs. 2.3.7. Capacidade de Chamada de Terminal
A capacidade de chamada indica a aceitação de capacidade de um terminal para cada
37
tipo de chamada que um terminal deverá suportar (voz, dados T.120, H.320, etc.). Um terminal pode reportar sua capacidade de chamada por meio de várias mensagens H.225.0, para auxiliar o gatekeeper a rotear chamadas. Já um gateway reporta sua informação de capacidade de chamada para auxiliar um gatekeeper a realizar balanceamento de carga através de gateways e para diminuir o número de tentativas de chamadas falhas. 2.3.8. Serviços de Identificação de Chamador
O serviço de identificação de chamador é um recurso que consiste em transmitir informações referentes à apresentação ou à restrição de informações, entre os terminais ou entre um gatekeeper e um terminal. Os tipos de identificação são: •
Número do chamador.
•
Número conectado.
•
Número chamado.
•
Número ocupado.
2.4. PROCEDIMENTOS DE SINALIZAÇÃO DE CHAMADAS
2.4.1. Fase A – Call Setup O call setup ocorre antes do fluxo da chamada ser estabelecido entre duas partes. É realizado através de mensagens de controle de chamada definidas na recomendação H.225.0 e pode acontecer de várias maneiras, de acordo com o cenário utilizado, explicado a seguir.
Quando dois terminais não estão conectados em nenhum gatekeeper e querem se comunicar, a troca de sinalização é realizada diretamente de um terminal ao outro. O terminal 1 (endpoint 1) envia a mensagem de setup (1) ao terminal chamado, para o (conhecido) identificador TSAP do canal de sinalização de chamada do terminal 2
38
(endpoint 2). O terminal chamado responde com as mensagens de call proceeding (2), alerting (3) e connect (4), ilustrados na figura 10.
Figura 10 - Call setup básico sem gatekeeper (fonte: ITU-T)
Com dois terminais registrados no mesmo gatekeeper existem duas formas dos mesmos realizarem a troca de sinalização. A primeira é quando os terminais se comunicam diretamente, ou seja, as mensagens de sinalização de chamada são enviadas de um terminal diretamente ao outro terminal, sem intermediação do gatekeeper .
Desta forma, somente as mensagens iniciais ARQ ( Admission Admission Request ,
mensagem de requisição para especificação da largura de banda), ACF Admission (Admission Confirm,
mensagem de confirmação) e ARJ ( Admission Reject , mensagem de
refeição), todas elas mensagens RAS, serão trocadas diretamente com o gatekeeper .
Figura 11 - Terminais registrados no mesmo gatekeeper , com sinalização direta (fonte: ITU-T)
39
Quando o gatekeeper age como intermediador de toda sinalização, todas as mensagens serão roteadas pelo gatekeeper , antes de chegar ao terminal chamado.
Figura 12 - Terminais registrados no mesmo gatekeeper , com sinalização roteada (fonte: ITU-T)
Na figura 13 o terminal chamador irá trocar a sinalização RAS com o gatekeeper (onde está registrado) e a sinalização de chamada será transmitida diretamente entre os terminais.
Figura 13 - Somente terminal chamador registrado, sinalização direta (fonte: ITU-T)
Caso a sinalização escolhida seja a roteada, o gatekeeper vai intermediar as mensagens de sinalização de chamada, mas não irá trocar mensagens RAS com o
40
terminal chamado.
Figura 14 - Somente terminal chamador registrado, sinalização roteada (fonte: IT U-T)
Na sinalização direta, o terminal 1 (endpoint 1), que não está registrado em nenhum gatekeeper ,
envia a mensagem de setup (1) diretamente ao terminal 2 (endpoint 2),
este sim registrado em um gatekeeper . Como o terminal 2 aceitou a chamada, ele envia a mensagem call proceeding (2) e em seguida inicia a troca de mensagens RAS com o gatekeeper no qual está registrado. Na seqüência as mensagens alerting (5) e connect (6) finalizam a sinalização.
Figura 15 - Chamador registrado no gatekeeper , sinalização direta (fonte: ITU-T)
Quando um terminal externo chama um terminal dentro de uma rede através de um gateway,
este se comporta igual a um terminal dentro da mesma rede, como se
41
estivesse em uma chamada terminal-terminal. O gateway deverá agir como um terminal, realizando toda conversão necessária para que o terminal externo faça corretamente a sinalização com o terminal da rede. O mesmo ocorre no caso de conferências do tipo multiponto centralizada. Todos os terminais devem trocar sinalização diretamente com o MCU e este vai fazer a sinalização de chamada como se fosse um terminal simples sinalizando com outro terminal. 2.4.2. Fase B – Comunicação Inicial e Troca de Capabilidade Após a troca de mensagens de setup da fase “A”, os terminais devem estabelecer a abertura do canal de controle H.245, se for o intuito de ambos os terminais. A abertura deste canal destina-se a troca de capabilidade e à abertura dos canais de mídia. As definições de capabilidade por sinal são as primeiras mensagens enviadas pelo canal de controle H.245, através da transmissão de mensagens do tipo terminalCapabilitySet .
A determinação de mestre-escravo deve se seguir após a troca de capabilidade entre os
terminais
através
das
MasterSlaveDeterminationAck (a
mensagens
MasterSlaveDetermination
ou
que for mais apropriada). A determinação mestre-
(Multipoint Conference Conference ) escravo é importante para casos onde a capabilidade de MC Multipoint
está presente nos dois terminais em comunicação. Assim é possível determinar qual MC será a ativa em uma conferência. Com o objetivo de conservar recursos, sincronizar sinalização de chamada e controle e reduzir o tempo do setup das chamadas foi definido um procedimento que torna possível encapsular mensagens H.245 em mensagens do canal de sinalização H.225.0, ao invés de estabelecer um canal H.245 separado. Esse processo é também chamado de tunelamento. O tunelamento pode ser cancelado a qualquer momento por ambos os terminais, fazendo com que as mensagens comecem a ser transmitidas em um canal separado H.245.
42
Quando não existe a necessidade de se enviar mensagens H.225.0 e uma mensagem H.245 precisa ser enviada, então é enviada a mensagem H.225.0 Facility, com o parâmetro reason contendo transportedInformation. O tunelamento é ativo quando a primeira mensagem H.225.0 trocada entre os dois terminais é enviada, uma mensagem H.225.0 com o parâmetro h245Tunnelling marcado como TRUE . 2.4.3. Fase C – Estabelecimento de Comunicação Áudio Visual
Após a troca de capabilidades e a determinação de mestre-escravo entre os terminais, os procedimentos da recomendação H.245 serão utilizados para abrir canais lógicos para os vários fluxos de informação. Os fluxos de áudio e vídeo serão transportados por identificadores TSAP dinâmicos, utilizando-se de um protocolo não orientado à conexão (UDP). Já as comunicações de dados serão transmitidas por um protocolo orientado à conexão (TCP). No estabelecimento dos canais lógicos, vários tipos de procedimentos (descritos na recomendação H.245) podem ocorrer de acordo com o tipo, topologia e finalidade da chamada. Alguns podem ser obrigatórios e outros opcionais como, por exemplo, a mudança de modo em um canal lógico, que minimiza a falha do áudio. Outro exemplo seria a associação de um canal lógico com um fluxo RTP dentro de uma conferência multiponto.
2.4.4. Fase D – Serviços de Chamadas
Existem seis tipos de serviços diferentes que podem ser utilizados durante o transcorrer de uma chamada qualquer. São eles: •
Alteração de largura de banda: a largura de banda é inicialmente estabelecida
43
e aprovada pelo gatekeeper durante as sinalizações de admissão. Depois de iniciada a troca de fluxo de informação, qualquer um dos terminais ou o próprio gatekeeper , mesmo em uma conferência a três ou mais participantes, pode solicitar a alteração de largura de banda. Recomenda-se este tipo de alteração quando um terminal for utilizar a largura de banda reduzida por um longo período de tempo, liberando desta forma largura de banda para outras chamadas concomitantes. •
Estado: utilizado pelo gatekeeper para determinar se um determinado terminal está ativo ou não, ou ainda se entrou em estado de falha. Através de uma seqüência de mensagens IRQ e IRR (H.225.0) enviada aos terminais (intervalo determinado pelos fabricantes dos terminais) é possível saber o estado em que cada terminal conhecido se encontra no momento.
•
Expansão de conferência ad hoc: este procedimento é opcional para terminais e gateways, mas obrigatório para um MC. Através deste procedimento é possível expandir uma conferência ponto a ponto para uma multiponto ad hoc, onde um dos terminais no mínimo precisa conter um MC.
•
Serviços
suplementares:
os
serviços
suplementares
foram
criados
originalmente para centrais telefônicas privadas baseadas em comutação de circuito. Na série de recomendações H.450.x do ITU-T, um quantidade considerável destes serviços foi especificada como serviços básicos, implementados agora em redes baseadas em comutação de pacotes [6]. Alguns destes serviços são: transferência, redireção, retenção de chamada, estacionamento de chamada, chamada em espera, etc. •
Cascateamento multiponto: o cascateamento acontece quando duas conferências distintas são conectadas uma a outra, através do MC de cada uma delas. Desta forma uma delas é determinada como MC mestre e a outra como escrava. Uma vez estabelecida uma conferência cascateada, tanto o terminal mestre como o escravo poderão convidar outro MC para participar da conferência, mas somente poderá existir um MC mestre para cada conferência cascateada.
•
Pausa e re-roteamento por uma terceira parte: é um procedimento que permite rotear ligações independentemente se o terminal possui suporte a serviço
44
suplementar. É utilizado para facilitar anúncios de pré-conexão e também para atrasar o estabelecimento de mídia H.245 quando o recurso de localização de usuário por gatekeeper estiver sendo utilizado. Na pausa, o terminal recebe uma mensagem H.245 onde ele ficará em estado de espera e com todos os canais lógicos fechados, até que o terminal remoto envie outra mensagem para terminar a pausa. Isso pode auxiliar uma entidade anunciadora, por exemplo, a enviar fluxo de informação e não receber nada do terminal em pausa. 2.4.5. Fase E – Finalização de Chamada
Uma chamada pode ser finalizada de duas maneiras: intermediada por um gatekeeper ou simplesmente por sinalização entre dois terminais em comunicação direta.
45
3. PROTOCOLO SIP (IETF)
3.1. INTRODUÇÃO
O Session Initiation Protocol ou simplesmente SIP, é um protocolo de controle baseado na camada de aplicação que estabelece, modifica e termina sessões multimídia. Os cinco elementos principais do SIP são: •
Localização de usuário: determinação do sistema final a ser utilizado para comunicação.
•
Disponibilidade de usuário: determinação da parte chamada a estabelecer comunicação.
•
Capabilidade de usuário: determinação do tipo de mídia e dos respectivos parâmetros a serem utilizados.
•
Setup
de sessão: determinação dos parâmetros de sessão a serem utilizados
pela parte chamadora e pela parte chamada, durante a fase de estabelecimento da chamada. •
Administração de sessão: transferência e terminação de sessão, modificação de parâmetros de sessão, chamada de serviços.
O protocolo SIP não é um sistema de comunicação verticalmente integrado. Para uma completa arquitetura multimídia, outros protocolos IETF podem ser utilizados (SDP, MEGACO, RTP, RTSP), embora o funcionamento e operações básicas do SIP não dependam destes protocolos adicionais. O SIP também não suporta serviços, ou melhor, ele provê somente premissas que podem ser utilizadas para implementar diferentes serviços. Outro detalhe importante é que o SIP não realiza o controle de conferência. Ele pode somente iniciar uma sessão SIP, mas o controle da conferência deve ser realizado por um protocolo específico. As informações contidas neste capítulo sobre SIP são baseadas em [2].
46
3.2. ESTRUTURA
O SIP é um protocolo dividido em camadas, listadas a seguir: •
A mais baixa camada é onde se encontra a sintaxe e codificação. Esta é especificada utilizando-se a gramática BNF (forma de Backus-Naur).
•
A segunda camada é a de transporte. Esta define como um cliente ou um servidor envia requisições e recebe respostas através da rede. Todos os elementos SIP contêm uma camada de transporte.
•
A terceira camada é a de transação, componente fundamental do SIP. Uma transação é uma requisição enviada por uma transação cliente (utilizando-se a camada de transporte) para uma transação de servidor, assim como as respostas a estas requisições. Esta camada lida com retransmissões da camada de aplicação, casamento de respostas às requisições e expiração de tempo da camada de aplicação. Qualquer tarefa que um UAC (User Agent Client ) cumpra é através de uma série de transações.
•
A quarta camada se chama usuário transação (TU – Transaction User ). ). Cada um dos elementos SIP, exceto o stateless Proxy, é um TU. Quando um TU deseja enviar uma requisição, ele cria uma instância de transação cliente e repassa juntamente com o endereço IP de destino e porta, e assim transporta para quem ele quer enviar a requisição.
3.3. DEFINIÇÕES
Para uma melhor compreensão da arquitetura SIP, os seguintes termos são de suma importância ser conhecidos: •
Address-Of-Record :
um AOR é um URI SIP ou SIPS que aponta para um
domínio com um serviço de localização que pode mapear um URI para outro URI quando um usuário estiver disponível. Tipicamente o serviço de localização é suprido pelos registros. Um AOR é freqüentemente considerado
47
como o endereço público do usuário. •
Back-To-Back User Agent:
entidade lógica que recebe uma requisição e a
processa como um UAS. Para saber como uma mensagem de requisição deve ser respondida ele age como um UAC e gera requisições. Ao contrário do servidor Proxy, ele mantêm o estado de diálogo e deve participar de todas as requisições enviadas nos diálogos que se estabeleceram. •
Call Stateful : Um proxy
é call stateful se ele retêm o estado para um diálogo
da requisição INVITE iniciadora até o BYE finalizador. •
Core: designa as funções específicas de um tipo particular de entidade SIP.
•
Diálogo: Um diálogo é o relacionamento SIP ponto a ponto entre dois UAs que persiste por algum tempo. Um diálogo é estabelecido por mensagens SIP, como a resposta 2xx para uma requisição INVITE. Um diálogo é identificado por um identificador de chamada, tag local e tag remoto.
•
Downstream :
É a direção de encaminhamento de mensagem de requisição
que vai do UAC ao UAS. •
Home Domain:
é o domínio provendo serviços para um usuário SIP.
Tipicamente, este é o domínio presente no URI do AOR de um registro. •
Outbound Proxy:
é um proxy que recebe requisições de um cliente, embora
este possa não ser o servidor resolvido pelo request-URI. Normalmente um UA tem seu outbound proxy configurado manualmente, ou pode aprender a localização de algum através de algum protocolo de descoberta. •
Proxy Server:
entidade intermediária que atua tanto como servidor como
cliente (quando se propõem a fazer requisições em nome de outros clientes). A função primordial do Proxy Server é roteamento, seu trabalho é garantir que a requisição é enviada para outra entidade o mais próximo possível do usuário alvo. Eles são úteis também para políticas de segurança (por exemplo, para garantir que um usuário tenha ou não permissão para realizar determinada chamada). Um Proxy interpreta e, se necessário, reescreve partes específicas de uma mensagem de requisição, antes de encaminhar ela. •
Redirect Server:
é um UAS que gera respostas 3xx para as requisições que
recebe, direcionando o cliente a contatar uma série de URIs alternativas. •
Registrar : é o servidor que aceita as requisições de REGISTER e
armazena as
48
informações que recebe no serviço de localização no domínio em que ele atua. •
Sessão: Da especificação SDP: “Uma sessão multimídia é uma série de remetentes e destinatários multimídia e os fluxos de dados que vão dos remetentes aos destinatários. Uma conferência multimídia é um exemplo de uma sessão multimídia” [7]. Como definido, a parte chamada pode ser convidada diversas vezes, por diferentes chamadas, para uma mesma sessão. Se o SDP for usado, uma sessão é definida pela concatenação dos nomes de usuário, ID de sessão, tipo de rede, tipo de endereço e elementos do endereço no campo origem.
•
SIP Transaction :
ocorre entre um cliente e um servidor e compreende todas
as mensagens da primeira requisição enviadas pelo cliente ao servidor, até uma resposta final (1xx) enviada do servidor para o cliente. Se a requisição é INVITE e
a resposta final é diferente de 2xx, a transação também inclui um
ACK para a resposta. Um ACK para uma resposta 2xx a uma requisição INVITE é uma transação separada. •
Stateful Proxy :
entidade lógica que mantêm os mecanismos de estado de
transação do cliente e servidor, durante o processo de requisição, também conhecido como transaction stateful proxy. •
Stateless Proxy : entidade lógica que não mantêm os mecanismos de estado de
transação do cliente e servidor. Um stateless Proxy encaminha qualquer requisição que recebe de forma downstream e toda resposta que recebe de forma upstream. •
Upstream :
É a direção de encaminhamento de mensagem de resposta que vai
do UAS ao UAC. •
User Agent Client (UAC) :
entidade lógica que cria uma nova requisição e
então utiliza o mecanismo de estado de transação cliente para enviá-la. O papel de UAC dura somente pela duração da transação. Em outras palavras, se uma parte do software inicia uma requisição, ele atua como UAC pelo tempo da duração daquela transação. Se receber uma requisição mais tarde, ele assume o papel de UAS para o processo da transação. •
User Agent Server (UAS) :
entidade lógica que gera respostas a requisições
49
SIP. Este tipo de resposta aceita, rejeita ou redireciona requisições. Este papel dura apenas pelo tempo desta transação. Em outras palavras, se um pedaço de software responde a uma requisição, ele atua como UAS pelo tempo da duração daquela transação. Se ele gerar uma requisição mais tarde, ele assume o papel de UAC para o processo desta transação. •
User Agent (UA) :
entidade lógica que pode atuar tanto como cliente como
servidor. Os servidores de proxy, localização e registrar são entidades lógicas, implementações podem combinar todos eles em um só aplicativo, como é o caso da plataforma Asterisk. 3.4. MENSAGENS SIP
O SIP é um protocolo que atua na camada de aplicação e é baseado em texto (utiliza a série de caracteres UTF-8). A similaridade de sintaxe das mensagens SIP com mensagens HTTP/1.1 é muito grande, embora não possamos considerar o SIP uma extensão do HTTP. Basicamente existem dois tipos de mensagens: requisição e resposta. Uma mensagem SIP genérica é formatada da seguinte forma: [Linha inicial] [Cabeçalho da mensagem] [CRFL (carriage-return line-feed )] )] [Corpo da mensagem]
3.4.1. Requisições
As mensagens de requisições distinguem-se por começarem com uma linha do tipo
50
requisição, constando o nome do método, o URI requisitado e a versão de protocolo. Existem seis tipos de método: REGISTER para informações de registro de contato, INVITE, ACK e CANCEL
para estabelecimento de sessões, BYE para terminar
sessões e OPTIONS para consultar servidores sobre suas capabilidades. O URI (Uniform Resource Indicators ) requisitado é o usuário ou serviço a quem a mensagem está sendo endereçada. Pode ser um URI SIP ou SIPS (SIP URI seguro). Por fim a versão SIP utilizada na mensagem, SIP/2.0 (versão 2.0), por exemplo.
3.4.2. Respostas
Na primeira linha das mensagens de resposta encontramos o estado da linha ou status line.
Ela é formada pela versão do SIP utilizado, um código formado por três
caracteres numéricos (que indica o resultado de uma requisição realizada) e uma pequena descrição textual acerca do significado do código numérico. O primeiro dígito do código numérico indica a classe de resposta enviada: •
1xx: Provisório, requisição recebida e continuando a processar a requisição.
•
2xx: Sucesso, a ação foi corretamente recebida, entendida e aceita.
•
3xx: Redireção, uma ação adicional é necessária para completar a requisição.
•
4xx: Erro de cliente, a requisição possui erro de sintaxe ou não pôde ser processada no servidor de destino.
•
5xx: Erro de servidor, o servidor falhou ao responder uma requisição aparentemente válida.
•
6xx: Falha global, a requisição não pôde ser processada em nenhum servidor.
3.5. COMPORTAMENTO GERAL DO USER AGENT O conceito de user agent é definido como sendo um sistema final formado por um
51
UAC, que gera requisições e um UAS que responde estas requisições. O UAC é capaz de gerar requisições baseado em estímulo externo (clique do mouse ou um sinal vindo da PSTN) e também processar respostas recebidas. O UAS é capaz de receber as requisições e gerar as respostas baseado na entrada de dados do usuário, estímulo externo, o resultado da execução de um programa ou algum outro mecanismo. 3.5.1. Comportamento do UAC
Uma requisição SIP válida formulada por um UAC deve conter no mínimo os seguintes parâmetros: •
To
– especifica o recipiente lógico de destino da requisição, ou o AOR do
usuário ou recurso que é o destino de tal requisição. •
From
– especifica a identidade lógica do remetente da requisição, o AOR do
usuário remetente. Opcionalmente pode-se colocar o nome de exibição a frente da identidade (assim como no To). •
CSeq
– serve como uma forma de identificar e ordenar transações. Ele
consiste de um número de seqüência e o método (o método deve ser igual ao enviado na requisição). •
Call-ID
– atua como um identificador único para agrupar uma série de
mensagens SIP. Este identificador precisa ser igual em todas as mensagens enviadas tanto pelo UAC como pelo UAS em um diálogo. A forma recomendada do call-id é “
[email protected]”. Por exemplo,
[email protected]. •
Max-Forwards
– serve para limitar o número de saltos que uma requisição
pode realizar em seu caminho até o destino. •
Via – Via – este
parâmetro serve para indicar o transporte utilizado para a transação
e identifica a localidade para onde a resposta deve ser enviada. Este parâmetro é somente preenchido após o transporte a ser utilizado para alcançar o próximo salto ser selecionado.
52
Uma vez computada a requisição, os procedimentos de DNS devem ser aplicados para determinação do destino, a não ser que contrariem alguma política local. O processamento das respostas por parte do UAC é primeiramente realizado pela camada de transporte do SIP e depois passada para a camada acima, de transação. Esta camada realiza o processamento da resposta e então repassa para a TU. A maior parte das respostas processadas pelo TU dependem do método, mas existem alguns comportamentos independentes do método: •
Erros da camada de transação.
•
Respostas irreconhecíveis.
•
Vias.
•
Respostas 3xx.
•
Respostas 4xx.
3.5.2. Comportamento do UAS Quando uma requisição fora de um diálogo é processada por um UAS, existe uma série de regras de processamento que são seguidas, independentemente do método utilizado. Se uma requisição for aceita, todas as mudanças de estado associadas com ela devem ser realizadas. Se a requisição for rejeitada, as mudanças de estado não devem ser realizadas. O processamento de requisições por parte do UAS inicia com a autenticação e depois inspeção de método. Se o método não for suportado o UAS deve gerar uma mensagem de resposta 405 (método não permitido). Caso o método seja suportado o processamento continua com a leitura do cabeçalho. Com o cabeçalho analisado e compreendido pelo UAS, segue-se o processamento de conteúdo, que é a leitura do corpo da mensagem.
53
Após a checagem inicial descrita acima, o processamento no UAS torna-se dependente de método ( REGISTER, OPTIONS, INVITE, BYE ). A partir deste momento inicia-se a geração da resposta por parte do UAS.
3.5.3. Comportamento do UAS stateless Um UAS stateless é aquele que não mantêm estado de transação. Ele responde às requisições normalmente, mas descarta qualquer tipo de estado que possa ter sido retido depois de uma resposta ter sido enviada. Quando um UAS stateless recebe uma retransmissão de requisição, ele gera uma resposta como se estivesse respondendo a primeira instância da requisição (esse comportamento exclui um stateless registrar ). ).
A função do UAS stateless é necessária primeiramente para manipular requisições não autenticadas, para a qual uma pergunta de desafio é criada. Se requisições não autenticadas fossem manipuladas de forma a manter o estado da transação, desta forma fluxos maliciosos de requisições não autenticadas poderiam criar grandes quantidades de estado de transação que poderiam tornar lento ou até mesmo cessar o processamento de chamadas em um UAS (conhecido como ataque de negação de serviço ou DoS). Algumas regras importantes para o UAS stateless: •
Não deve enviar mensagens de resposta provisórias (1xx).
•
Não deve retransmitir respostas.
•
Deve ignorar requisições ACK e CANCEL.
•
O cabeçalho da resposta deve ser gerado na forma stateless, gerando o mesmo tag para a mesma requisição de maneira de maneira consistente.
54
3.6. CANCELANDO UM REQUEST
Para o cancelamento de uma requisição enviada, utiliza-se o método CANCEL. A requisição CANCEL solicita ao UAS que pare de processar determinada requisição previamente enviada e que gere uma resposta de erro para esta requisição. Um CANCEL não vai ter efeito sobre uma requisição já processada pelo UAS. Ele é utilizado e recomendado para requisições INVITE, que podem demorar um longo período de tempo para serem respondidas. O CANCEL pode ser enviado a partir de um UAC e um proxy. 3.7. REGISTROS Quando um usuário quer iniciar uma sessão com outro usuário, o SIP deverá descobrir em qual host este usuário está alcançável. Para que isso ocorra, os elementos do SIP consultam um serviço abstrato chamado location service, que provê bindings de endereços de um determinado domínio. Esses bindings de endereço mapeiam um SIP URI recebido, apontando para um ou mais URIs, que de alguma forma estão mais próximos do usuário final. O registro funciona como um mecanismo que irá alimentar a base de dados do location service,
que armazenará as informações obtidas através dos registros
realizados. Em um registro é mandatório haver uma requisição REGISTER destinada a um UAS especial chamado registrar. Um registrar funciona como uma interface de entrada para um location service de determinado domínio, lendo e escrevendo mapeamentos baseados no conteúdo das requisições REGISTER. O location service é então tipicamente consultado por um servidor proxy que é responsável por rotear requisições para o domínio. As implementações de um location service não são especificadas na RFC do SIP, mas um registrar deve ter a capacidade de escrever e ler dados deste location
55
service ,
assim como um servidor de proxy ou de redireção deve poder ler os mesmos
dados.
Figura 16 - Exemplo de requisição REGISTER (fonte: IETF)
3.8. INFORMAÇÕES DE CAPABILIDADE
O método utilizado para solicitar informações de capabilidade é o OPTIONS. Este método é enviado de um UA para outro UA para descobrir informações sobre os métodos suportados, tipos de conteúdo, ramais, codec's, etc, de cada um dos UA envolvidos, sem iniciar o ring para a parte chamada, ou seja, ainda na fase de estabelecimento de chamada.
Figura 17 - Exemplo de requisição OPTIONS (fonte: IETF)
56
Figura 18 - Exemplo de resposta OPTIONS (fonte: IETF)
3.9. DIÁLOGOS
Um diálogo pode ser definido como uma relação SIP ponto a ponto entre dois UAs, que persiste por um determinado tempo. Esse tipo de relação colabora com o seqüenciamento de mensagens entre UAs e o correto roteamento de requisições e respostas entre os pontos. A identificação do diálogo é representada pelo call-ID, uma marcação (tag) remota e uma local. Um ID de diálogo não é o mesmo em cada um dos UAs envolvidos no diálogo. A marcação local é idêntica a marcação remota, mas devemos considerar estas marcações como tokens que facilitam a geração de IDs únicos de diálogo. Um ID de diálogo é também associado com todas as respostas e qualquer requisição que contenha uma marcação no campo To. Dependendo se o UA é um UAS ou um UAC, ele tem a computação do ID de diálogo diferente. Para o UAC, o call-ID do ID de diálogo é o call-ID da mensagem, a marcação remota é igual à marcação no campo To e a marcação local é igual à marcação do campo From. No UAS, as marcações são o contrário. Um diálogo contém certos pedaços de estado necessários para futuras transmissões de mensagem dentro do diálogo. Este estado consiste em: 57
•
ID de diálogo
•
Número de seqüência local
•
Número de seqüência remota
•
URI local
•
URI remoto
•
Target remoto
•
Um flag booleano chamado “secure”
•
Route Set (lista
de URIs ordenadas, que são servidores que necessitam serem
transversos para enviar uma requisição a um ponto) 3.10. SESSÃO
Uma sessão (áudio, vídeo ou jogo) é estabelecida depois que um UA gera uma requisição INVITE para um servidor. A requisição pode ser encaminhada por algum proxy ,
eventualmente chegando a um ou mais UAS’s que podem potencialmente
aceitar o convite. Estes UAS’s podem aceitar o convite depois de algum tempo (significando que a sessão está para ser estabelecida) com o envio de mensagens de resposta 2xx. Se o convite não foi aceito, mensagens 3xx, 4xx, 5xx e 6xx serão enviadas ao UAC, dependendo da razão da rejeição. Depois de enviar a resposta final, o UAS pode ainda enviar mensagens provisórias do tipo 1xx para advertir o UAC do progresso de contato com a parte chamada. Devido ao tempo prolongado que um UAC possa demorar a receber uma mensagem final, os mecanismos de confiabilidade para as transações INVITE diferem de outras requisições como OPTIONS. Para cada resposta final recebida, o UAC deve enviar um ACK. Quando a resposta final é entre 300 e 699, o processamento do ACK é realizado na camada de transação e segue uma série de regras. Para respostas 2xx, o ACK é gerado pelo core do UAC. Uma resposta 2xx para um INVITE estabelece uma sessão e também cria um diálogo entre os UA’s. Quando diversas respostas 2xx são recebidas de diferentes UA’s remotos, cada mensagem 2xx estabelece um diálogo diferente, que serão parte da 58
mesma chamada. Um sessão pode ser alterada também, o que envolve mudança de endereço ou porta, adição ou remoção de fluxo de mídia, entre outras. Isso ocorre quando um novo INVITE é enviado no mesmo diálogo que estabeleceu a sessão, este procedimento é também conhecido como re-INVITE. Para terminar uma sessão existem três maneiras, a primeira através do recebimento de qualquer mensagem de resposta que não seja 2xx, a segunda maneira é pelo envio da requisição BYE e a terceira pelo envio da requisição CANCEL, que pode ocorrer quando determinado UAS tome muito tempo para enviar uma resposta final ao UAC.
3.11. PROXY Um proxy SIP é um elemento que roteia requisições para UAS’s e respostas para UAC’s. Uma requisição, por exemplo, pode passar por diversos servidores proxy em sua trajetória até o UAS. Cada um destes servidores realizarão decisões de roteamento, modificando a requisição antes de encaminhá-la para o próximo servidor proxy .
As respostas virão no mesmo caminho inverso, passando por todos os
servidores da ida.
3.11.1. Stateful proxy Um proxy opera em modo stateful quando ele guarda informações de estado de transação, sobre cada uma das requisições recebidas e encaminhadas após processamento. A informação armazenada é utilizada como parâmetro no processamento de futuras mensagens associadas com esta requisição. Em modo stateful, o proxy é um mecanismo de processamento de transações SIP. Logicamente falando, um proxy stateful possui uma transação de servidor associada com uma ou mais transações cliente, através de um componente de processamento de
59
proxy
de camada superior, conhecido como proxy core.
Figura 19 - Modelo de Proxy Stateful (fonte: IETF)
A mensagem de requisição, após ter sido processada pela transação de servidor, é passada ao proxy core, que vai determinar para onde rotear a requisição, escolhendo uma ou mais localizações de próximo-salto. Uma requisição sainte é processada para cada localização de próximo-salto pela própria transação associada. O proxy core coleta as respostas das transações de cliente e usa-as para enviar respostas para a transação de servidor. Um proxy stateful precisa realizar as seguintes tarefas para todas as requisições que receber: •
Validar a requisição
•
Pré-processar informações de roteamento
•
Determinar para onde vai a requisição
•
Encaminhar a requisição para cada local determinado
•
Processar todas as respostas
60
3.11.2. Stateless proxy Quando um proxy está no modo stateless, ele simplesmente age como um encaminhador de mensagens. Muito do processamento executado em um stateful proxy
é igual a um stateless proxy.
Um stateless proxy não têm noção nenhuma de transação. Ele coleta as mensagens diretamente da camada de transporte e, como resultado, não retransmite mensagens por conta própria. Ele pode somente encaminhar todas as retransmissões que recebe apenas, pois este tipo de proxy não terá a capacidade de discernir um retransmissão de uma mensagem original. Agindo de forma stateless ele também não pode enviar nenhuma mensagem provisória como um TRYING (100), ao contrário do proxy stateful.
3.12. TRANSAÇÕES
O SIP é um protocolo transacional, interações entre componentes acontecem em uma série de trocas de mensagens independentes. Uma transação consiste em uma mensagem de requisição e qualquer resposta para a mesma, o que inclui uma mensagem provisória ou uma mensagem final. As transações possuem o lado cliente e o lado servidor, um envia a mensagem e o outro responde, respectivamente. O lado cliente é chamado transação cliente e o lado do servidor transação servidor. Estas transações são funções lógicas embutidas em qualquer número de elementos. Elas existem em UA’s e servidores stateful proxy. No exemplo da figura 20 o UAC executa uma transação cliente e seu servidor de outbound proxy
executa uma transação de servidor. Este servidor por sua vez executa
uma transação cliente através de uma mensagem de requisição com destino a transação de servidor do servidor de inbound proxy. Este proxy executa o mesmo procedimento com destino ao UAS, que enviará a mensagem de resposta, com os processos acontecendo pelo caminha inverso.
61
Figura 20 - Relacionamento de transações (fonte: IETF)
3.13. TRANSPORTE
A camada de transporte é responsável pela transmissão de requisições e respostas sobre transportes de rede, incluindo a determinação do tipo de conexão a ser utilizada para uma requisição ou resposta em caso de transportes orientados à conexão. Esta camada é responsável pelo gerenciamento de conexões persistentes de protocolos de transporte tais como TCP e SCTP, ou TLS sobre TCP/SCTP, incluindo aqueles abertos a camada de transporte. Estas conexões são indexadas por uma tuplas formada pelo endereço, porta e protocolo de transporte. Quando uma conexão é aberta pela camada de transporte, este índice é definido com o endereço IP, porta e transporte. Quando a conexão é aceita pela camada de transporte, este índice é definido com o endereço IP, porta e transporte da fonte. Note que, sendo o número de porta fonte efêmero ou selecionado por procedimentos, conexões aceitas pela camada de transporte não serão reutilizadas, na maioria das vezes. O resultado é que duas entidades proxy em uma relação ponto a ponto, utilizando-se de transporte orientado à conexão, freqüentemente terão duas conexões em curso, uma para cada direção nas transações.
62
3.14. CAMPOS DE CABEÇALHO
Abaixo se encontra a lista completa de campos de cabeçalho de mensagens SIP e respectiva descrição, muito semelhante à semântica e sintaxe do HTTP/1.1, característica do SIP. •
Accept :
especifica certos tipos de mídia que são aceitáveis para uma resposta
[8]. Em caso de ausência, o servidor deve assumir o valor padrão “application/sdp”. Em caso de parâmetro vazio, isso significa que nenhum formato é aceitável. •
Accept-Encoding:
similar ao accept , mas restringe a codificação de conteúdo
aceitável na resposta. •
Accept-Language:
indica o idioma preferido nas frases de razão, descrições
de seção ou respostas de estado, carregadas como corpo de mensagem na resposta. •
Alert-Info:
em mensagens de INVITE, representa um tom de ring alternativo
para o UAS. Nas mensagens 180 (RINGING), representa um ringback alternativo para o UAC. •
Allow: lista a série de métodos suportados pelo UA gerador da mensagem.
•
Authentication-Info: provê autenticação mútua com HTTP digest .
•
Authorization: contêm as credenciais de autenticação de um UA.
•
Call-ID:
identifica um convite particular único ou todos os registros de um
cliente em particular. •
Call-Info:
provê informações adicionais sobre o chamador ou a parte
chamada. O parâmetro purpose determina a finalidade da informação. •
Contact :
Provê o URI cujo significado depende da mensagem de requisição
ou resposta envolvida. Este campo pode conter o nome de exibição, uma URI com todos os parâmetros URI e parâmetros de cabeçalho. •
Content-Disposition:
descreve como o corpo da mensagem deve ser
interpretado. •
Content-Encoding:
indica quais codificações de conteúdo foram aplicadas ao
63
corpo da mensagem e quais mecanismos decodificadores devem ser aplicados. •
Content-Language: idioma do conteúdo
•
Content-Length: tamanho do corpo da mensagem, em número de bytes.
•
Content -Type:
indica o tipo de mídia do corpo da mensagem enviado ao
destinatário. •
CSeq:
formado por um número decimal e o método utilizado, serve para
ordenar transações dentro de um diálogo. •
Date: contêm data e hora
•
Error - Info 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 : proxies
utilizado por qualquer método SIP para limitar o número de
ou gateways que podem encaminhar a requisição para um próximo
servidor. O valor recomendado inicial é 70 (vai sendo decrementado). •
Min- Expires 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 Authenticate:
contêm um desafio de autenticação (no sentido de
criptografia e autorização). •
Proxy-Authorization:
permite ao cliente se identificar perante um proxy que
requer autenticação. •
Proxy-Require:
indica recursos sensíveis aos proxies que precisam ser
suportados pelo proxy. •
Record-Route:
inserido por proxies em requisições para forçar futuras
requisições em um diálogo a serem roteadas pelo proxy. •
Reply-To:
este campo contêm um URI lógico de retorno que pode ser 64
diferente do campo From de cabeçalho. •
Require:
utilizado por UACs para avisar UASs sobre as opções que o UAC
espera que o UAS suporte, para processamento da requisição. •
Retry-After :
valor em segundos utilizado em mensagens de resposta para
indicar quanto tempo o serviço é esperado permanecer indisponível para o cliente requisitante. •
•
Route: força o roteamento de uma requisição para uma lista de proxies. Server :
informação sobre o software utilizado pelo UAS para manusear a
requisição •
Subject :
provê um sumário ou indica a natureza da ligação, permitindo
filtragem de ligação sem ter que analisar a descrição de sessão. •
Supported : enumera todas as extensões suportadas pelo UAC ou UAS.
•
Timestamp: descreve quando um UAC enviou a requisição para o UAS.
•
To: especifica o
•
Unsupported : lista os recursos não suportados pelo UAS.
•
User - Agent Agent : contêm informações sobre o UAC originador da requisição.
•
Via: indica o
destinatário lógico da requisição.
caminho tomado pela requisição até então e o caminho que deve
ser seguido no roteamento das respostas. O parâmetro Branch ID no valor de cabeçalho do Via serve como um identificador de transação, utilizado pelos proxies para detecção de loops. •
Warning:
utilizado para carregar informações adicionais sobre o estado de
uma resposta. São enviados em mensagens de resposta e contêm um código de três dígitos decimais, um host name e um texto de warning. •
WWW-Authenticate: contêm um
desafio de autenticação.
3.15. CÓDIGOS DE RESPOSTA
Todos os códigos de resposta são consistentes com os códigos de respostas presentes no HTTP/1.1. Algumas respostas do HTTP/1.1 não são apropriadas para o SIP e vice-versa. O SIP, porém, implementa uma nova classe, a 6xx.
65
3.15.1. Respostas provisórias 1xx
As respostas provisórias, também conhecidas como respostas informativas, indicam que o servidor contatado está executando alguma ação e não possui no momento uma resposta definitiva para aquela requisição. Um servidor envia uma mensagem provisória quando ele espera que a resposta definitiva demore mais que 200ms. •
100 TRYING: indica que o servidor de próximo salto recebeu a requisição e alguma ação não especificada está sendo tomada para esta chamada. Quando o UAC recebe esta mensagem, automaticamente cessa o envio de INVITE.
•
180 RINGING: O UA receptor da mensagem INVITE está tentando alertar o usuário.
•
181 CALL IS BEING FORWARDED: um servidor pode utilizar este estado para indicar que a mensagem está sendo direcionada para uma série de destinos diferentes.
•
182 QUEUED: a parte chamada está temporariamente indisponível, mas o servidor decidiu enfileirar a chamada ao invés de rejeitá-la.
•
183 SESSION PROGRESS: convenciona informação sobre o progresso de uma chamada que não foi por algum motivo classificada.
3.15.2. Resposta de sucesso 2xx
•
200 OK: indica que a requisição obteve êxito
3.15.3. Respostas de redireção 3xx
Respostas do tipo 3xx provêem informação sobre a nova localização do usuário ou serviços alternativos que podem satisfazer a chamada. •
300 MULTIPLES CHOICES: dado um endereço na requisição, esta resposta
66
retorna diversas alternativas para o UAC selecionar sua preferida. •
301 MOVED PERMANENTLY: o usuário requisitado não existe mais no URI solicitado e deve tentar novamente através de um novo endereço dado pelo campo de cabeçalho contact .
•
302 MOVED TEMPORARILY: equivalente ao 301, mas com prazo de validade limitado, podendo ter seu tempo indicado por uma mensagem EXPIRES ou o parâmetro expires no campo de cabeçalho contact .
•
305 USE PROXY: o recurso requisitado deve ser acessado por um proxy dado pelo campo contact.
•
380 ALTERNATIVE SERVICE: a chamada não teve sucesso, mas existem alternativas possíveis. A padronização desta mensagem é assunto para futura discussão.
3.15.4. Resposta de falha 4xx
As respostas 4xx são definitivas e enviadas de servidores específicos. Este tipo de requisição não pode ser enviada ao mesmo servidor seguidamente, mas sim para servidores diferentes, onde pode receber uma resposta positiva. •
400 BAD REQUEST: a requisição não foi compreendida devido a sintaxe mal formada.
•
401 UNAUTHORIZED: a requisição requer autenticação de usuário. Este tipo de resposta são emitidas por UASs e registrars.
•
402 PAYMENT REQUIRED: reservado para uso futuro.
•
403 FORBIDDEN: o servidor entendeu a requisição, mas nega-se a processála. Autorização não resolve o problema dado por esta mensagem.
•
404 NOT FOUND: usuário não existe no domínio especificado.
•
405 METHOD NOT ALLOWED: o método especificado na request-line foi entendido, mas não é permitido pelo URI requisitado.
•
406 NOT ACCEPTABLE: os recursos identificados pela requisição são
67
somente capazes de gerar entidades de resposta que possuam características de conteúdo não aceitáveis de acordo com o campo de cabeçalho accept , enviado na requisição. •
407 PROXY AUTHENTICATION REQUIRED: similar ao 401, porém indica que o cliente necessita autenticar a si mesmo com o proxy.
•
408 REQUEST TIMEOUT: o servidor não conseguiu produzir uma resposta em determinado intervalo de tempo.
•
410 GONE: o recurso requisitado não está mais disponível e nenhum endereço de encaminhamento é conhecido.
•
413 REQUEST ENTITY TOO LARGE: o servidor está recusando-se a aceitar a requisição porque o corpo da mensagem de requisição é maior do que o servidor pode processar.
•
414 REQUEST-URI TOO LONG: o request-URI é muito longo para ser interpretado pelo servidor.
•
415 UNSUPPORTED MEDIA TYPE: o servidor está negando a requisição porque o formato do corpo da mensagem está em um formato não suportado pelo servidor, pelo método requisitado.
•
416 UNSUPPORTED URI SCHEME: o esquema da URI é desconhecido ao servidor.
•
420 BAD EXTENSION: o servidor não entende a extensão de protocolo especificado em um campo de cabeçalho proxy-require ou require.
•
421 EXTENSION REQUIRED: o UAS necessita de uma extensão em particular para processar a requisição, mas esta não está listada no campo de cabeçalho supported da requisição.
•
423 INTERVAL TOO BRIEF: o servidor está negando a requisição por que o tempo de expiração do recurso é muito curto.
•
480 TEMPORARILY UNAVAILABLE: o sistema final da parte chamada foi contata com sucesso, mas a parte chamada não está disponível no momento (não está autenticada, por exemplo).
•
481 CALL TRANSACTION DOES NOT EXIST: a requisição recebida não pertence a nenhuma transação ou diálogo.
•
482 LOOP DETECTED: o servidor detectou um loop.
68
•
483 TOO MANY HOPS: requisição recebida com o parâmetro Max-forwards igual a zero.
•
484 ADDRESS INCOMPLETE: o request-URI foi recebido incompleto.
•
485 AMBIGUOUS: o URI requisitado é ambíguo e uma lista de URIs possivelmente não ambíguas pode ser enviada no parâmetro contact.
•
486 BUSY HERE: o contato foi realizado com sucesso, mas a parte chamada não pode ou não quer receber uma ligação adicional.
•
487 REQUEST TERMINATED: a requisição foi terminada por um BYE ou CANCEL.
•
488 NOT ACCEPTABLE HERE: têm o mesmo significado da mensagem 606, mas somente se aplica ao recurso endereçado especificamente pelo request-URI.
•
491 REQUEST PENDING: a requisição foi recebida pelo UAS que possui uma requisição pendente dentro do mesmo diálogo.
•
493 UNDECIPHERABLE: a requisição recebida pelo UAS contêm o corpo MIME criptografado e não possui a chave para decifrá-lo.
3.15.5. Resposta de falha de servidor 5xx
Estas respostas são enviadas pelo servidor quando o próprio cometeu um erro. •
500 SERVER INTERNAL ERROR: o servidor encontrou uma condição inesperada que o preveniu de processar determinada requisição.
•
501 NOT IMPLEMENTED: o servidor não possui implementado a facilidade requisitada para processar a requisição.
•
502 BAD GATEWAY: o servidor, agindo como gateway ou proxy, recebeu uma resposta inválida do próximo salto (servidor).
•
503 SERVICE UNAVAILABLE: o servidor está temporariamente incapaz de processar a requisição devido a sobrecarga temporária ou manutenção de servidor.
•
504 SERVER TIME-OUT: o servidor não recebeu resposta em tempo hábil
69
de um servidor externo, para completar o processamento da requisição. •
505 VERSION NOT SUPPORTED: o servidor não suporta, ou recusa-se a suportar a versão do protocolo SIP que foi utilizada na requisição.
•
513 MESSAGE TOO LARGE: o tamanho da mensagem de requisição excedeu as capacidades do servidor.
3.15.6. Respostas de falha global 6xx
As resposta 6xx indicam que o servidor possui uma informação definitiva sobre um usuário em particular, não somente uma instância em particular indicada no requestURI.
•
600 BUSY EVERYWHERE: o sistema final da parte chamada foi contatado com sucesso, mas a parte chamada não deseja aceitar a ligação.
•
603 DECLINE: a máquina da parte chamada foi contata com sucesso, mas explicitamente nega-se a aceitar a ligação.
•
604 DOES NOT EXIST ANYWHERE: o servidor têm autoridade suficiente para indicar que o usuário indicado no request-URI não existe em lugar nenhum.
•
606 NOT ACCEPTABLE: o UA foi contatado com sucesso, mas alguns aspectos da descrição de sessão como mídia requisitada, largura de banda ou estilo de endereçamento não foram aceitas.
3.16. USO DE AUTENTICAÇÃO HTTP
O protocolo SIP provê autenticação baseada no modelo HTTP, com um mecanismo de desafio (challenge) stateless (não guarda estado). A autenticação provê garantia de identidade da entidade SIP. Uma vez que o originador foi autenticado, o destinatário pode decidir se aceita ou não a requisição em questão.
70
O mecanismo de autenticação digest provê autenticação de mensagem e proteção de resposta somente, sem garantir a integridade ou confidencialidade da mensagem. Medidas de proteção devem ser tomadas em níveis superiores de autenticação para prevenir ataques ativos que possam modificar requisições e respostas SIP. Devido à fraca segurança da autenticação “Básica”, o seu uso foi depreciado. Servidores não devem aceitar credenciais utilizando-se do esquema de autenticação “Básica” assim como não devem lançar “desafios” com este tipo de esquema. O UAS utiliza a mensagem de resposta 401 (UNAUTHORIZED) para desafiar a identidade de um UAC. Servidores de registrar e redirect também devem utilizar a mensagem 401, ao contrário dos servidores proxy, que devem utilizar a mensagem 407 (PROXY AUTHENTICATION REQUIRED).
71
4. ANÁLISE COMPARATIVA ENTRE H.323 E SIP
O H.323 (ITU-T) e SIP (IETF) são os protocolos de sinalização para comunicação multimídia mais utilizados do mercado atualmente. Cada um dos protocolos possui origens bem distintas. Enquanto o H.323 foi criado pelo ITU-T, entidade que padroniza tudo relacionado a telecomunicações, o SIP surgiu dos estudos do IETF, organização direcionada a pesquisa e desenvolvimento da Internet . O H.323 surgiu como um protocolo para comunicações multimídia em ambiente LAN sem garantia de qualidade de serviço (QoS). Com o passar do tempo, as pesquisas em torno do protocolo passaram a abordar métodos mais complexos, inerentes a telefonia de Internet [9]. Este protocolo herda características de sinalização do protocolo Q.931 ISDN, encontrada nas redes de circuito comutado. O SIP foi desenvolvido pelo grupo de trabalho MMUSIC do IETF e possui uma visão diferente do ITU-T, direcionada ao ambiente da Internet . Muitos dos campos de cabeçalho, regras de codificação, códigos de erro e mecanismos de autenticação são oriundos do HTTP. O SIP têm o objetivo de prover serviços equivalentes ao H.323, mas com uma abordagem mais simplificada, baseada em serviços da web. É importante ressaltar que as diferenças entre os dois protocolos não influenciam no QoS para telefonia de Internet , visto que o protocolo que é responsável pelo transporte da mídia é o RTP em ambos os casos [9]. 4.1. COMPLEXIDADE
Não há dúvidas na maior complexidade do protocolo H.323 em relação ao SIP. A herança das redes de circuito comutado faz com que a pilha de protocolos sob o H.323 seja extensa. O SIP é mais simples, ao se espelhar em métodos oriundos do HTTP. O H.323 define algumas centenas de elementos enquanto o SIP possui apenas 72
algumas dezenas de cabeçalhos, cada um com menos parâmetros, porém contendo mais informação. Uma simples interação SIP funciona com apenas quatro cabeçalhos (To, From, Call-ID e CSeq) e três tipos de requisição (INVITE, ACK e BYE) [9]. O H.323 utiliza representação binária em suas mensagens, baseado no ASN.1 e PER ( packed 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, stateful,
enquanto no SIP os elementos trabalham tanto em forma stateless ou dependendo da operação [9].
4.2. EXTENSIBILIDADE E MODULARIDADE
A definição comumente conhecida por extensibilidade é a capacidade de se promover expansões e melhorias em um sistema qualquer, com mínimos impactos para isso. E este é um parâmetro de análise importante quando se comparam dois protocolos de sinalização de voz sobre IP, pois a extensibilidade influencia comercialmente e tecnicamente a escolha do protocolo a ser utilizado. O SIP não define explicitamente os requisitos de compatibilidade entre versões, o que resulta em redução do tamanho do código e menos complexidade. No entanto pode ter o efeito adverso de novas versões não suportarem recursos de versões
73
anteriores. O H.323 por outro lado requer compatibilidade total de versões anteriores com as novas versões, o que resulta em um código extenso para implementação [11]. A adição e evolução de recursos e serviços são consideradas mais flexíveis no SIP do que no H.323. O SIP possui mecanismos de extensibilidade embutidos no código, é baseado em texto e a maior parte de sua estrutura é modular. O H.323 é um tanto complexo para definição de novos recursos e serviços, requerendo o código de fabricantes para serem especificados [11]. A modularidade do SIP é notória quando analisamos a forma como outros protocolos podem ser utilizados com o SIP, não necessitando de maiores modificações no núcleo funcional do SIP. A interação de diversos protocolos sob o H.323 acaba tornando-o mais fechado e menos maleável para interações com outros protocolos [11]. Uma vantagem do H.323 é a utilização de codecs , que necessitam ser registrados junto ao IANA (no caso do SIP) antes de qualquer implementação. No H.323 não existe este tipo de requisito [11].
4.3. ESCALABILIDADE
O suporte a um número elevado de domínios possui visões diferentes de diversos autores, mas existe equivalência entre SIP e H.323 [11]. O H.323 surgiu originalmente para operar em simples segmentos de LAN. A necessidade de implementações em ambientes mais complexos fez com que as forças tarefa do ITUT desenvolvessem recomendações que preenchessem as lacunas herdadas das primeiras versões. O SIP por sua vez teve seu início já visando estes tipos de ambientes. Hoje podemos dizer que ambos possuem os mesmos recursos para operar em diversos domínios diferentes, cada um agindo de uma forma específica. A habilidade de manipular um grande número de ligações é relativa. Ambos os
74
protocolos operam em modo stateful e stateless, sendo que o H.323 possui a maioria das funcionalidades em modo stateful. O SIP utiliza em sua maior parte operações no modo stateless, que teoricamente geram carga menor de processamento ao servidor, mas como mencionado, é relativo e depende do tipo de aplicação e implementação. O tipo de operação influencia na escalabilidade do protocolo, visto que quanto mais estados uma entidade guardar, menor será a escalabilidade em vista da maior complexidade envolvida [11].
4.4. SERVIÇOS
Os serviços suportados por ambos os protocolos são equivalentes, embora implementados de formas diferentes. O H.323 padroniza os serviços através da recomendação ITU-T H.450 enquanto o SIP não define explicitamente em sua RFC principal, apenas em white papers e outras RFC informativas [11]. O tempo para aquisição de serviços também é equivalente nos dois protocolos, quando utilizando UDP. A diferença é que o H.323 estabelece uma conexão de backup
via TCP paralelamente ao UDP, enquanto o SIP o faz seqüencialmente, após
falha do UDP [11]. 4.5. SEGURANÇA
O H.323 utiliza-se da série de recomendações H.235, que foi reorganizada em várias partes, hoje contando do H.235.0 até o H.235.9, listadas a seguir [1]: •
H.235.0 - H.323 security: Framework for security in H series (H.323 and other H.245-based) multimedia systems.
•
H.235.1 - H.323 security framework: Baseline security profile
75
•
H.235.2 - H.323 security framework: Signature security profile
•
H.235.3 - H.323 security: Hybrid security profile
•
H.235.4 - H.323 security: Direct and selective routed call security
•
H.235.5 - H.323 security: Framework for secure authentication in RAS using weak shared secrets
•
H.235.6 - H.323 security framework: Voice encryption profile with native H.235/H.245 key management
•
H.235.7 - H.323 security framework: Usage of the MIKEY key management protocol for the Secure Real Time Transport Protocol (SRTP) within H.235
•
H.235.8 - H.323 security: Key exchange for SRTP using secure signaling channels
•
H.235.9 - H.323 security framework: Security gateway support for H.323
A necessidade de perfis de segurança no H.323 foi primeiramente suprida em novembro de 2000, quando o ITU-T divulgou a recomendação H.235 versão 2, que provia diferentes níveis de segurança, não definidos no H.323 em si. A mais nova e importante adição à esta série foi o suporte a SRTP (Secure Real Time Transport Protocol) [10].
O SIP suporta autenticação de chamador e chamado por meio de mecanismos HTTP. A autenticação de segurança criptografada é suportada salto a salto por meio de SSL/TSL, embora o SIP possa utilizar qualquer mecanismo de segurança da camada de transporte ou similar HTTP, como SSH ou S-HTTP. O SIP também define autenticação fim a fim e criptografia utilizando-se de PGP ou S/MIME [12].
76
5. CONCLUSÃO
O início do H.323 e SIP, como mencionado várias vezes neste trabalho, foram distintos. O SIP surgiu com o intuito de ser uma versão ponto a ponto do protocolo SAP (session announcement protocol ) e o H.323 como um protocolo multimídia para operação somente em segmentos de LAN [12]. Com a crescente demanda de novos serviços e diferentes tipos de ambientes, as evoluções foram acontecendo naturalmente, percorrendo caminhos diferentes até chegarem às versões atuais (que continuam recebendo novos aperfeiçoamentos constantemente nos dois protocolos). No meio acadêmico, o que se nota é que não há meio termo. Existem defensores para cada um dos protocolos, porém poucos que aceitam os dois como protocolos equivalentes. Em se tratando de mercado corporativo (principal foco dos dois protocolos) nota-se um crescente número de fabricantes e desenvolvedores SIP. Originalmente a maior parte das implementações corporativas era H.323. O SIP criou uma espécie de marketing “pessoal” no mercado, enfatizando sua fácil implementação e desenvolvimento. O que aconteceu na verdade é que o H.323 sofreu com a idéia de operar sobre redes distintas e domínios diversos durante muito tempo. A dificuldade de transposição sobre firewalls e NAT limitou a utilização do H.323 em redes com grande capilaridade de topologias. A demanda por serviços de voz sobre IP trafegando em ambiente de Internet cresceu muito, chegando até mesmo a usuários residenciais e o SIP preencheu esta lacuna, inicialmente com serviços simples e eficientes. Hoje os protocolos são quase equivalentes (e tendem a serem completamente equivalentes), com algumas diferenças a serem observadas: •
Os serviços suplementares são mais rigorosamente definidos no H.323 [11], e assim
menos
suscetíveis
a
problemas
de
interoperabilidade.
A
compatibilidade entre versões é maior no H.323, além da tradicional interoperabilidade com a PSTN, fruto da origem ITU-T. •
A complexidade do H.323 tornou o SIP uma alternativa de protocolo mais
77
fácil de desenvolvimento e implementação por parte de fabricantes. •
Nota-se um crescente número de terminais SIP sendo comercializados por custos menores que terminais H.323, popularizando ainda mais aplicações em SIP, como a plataforma open-source Asterisk.
•
A maioria esmagadora de fabricantes de equipamentos de videoconferência utiliza a pilha de protocolos do H.323, sendo o SIP um protocolo ainda pouco utilizado para tal aplicação.
78
6. REFERÊNCIAS BIBLIOGRÁFICAS
[1] ITU-T, H.323v6 Recommendation: packet-based multimedia communications systems. 2006. [2] IETF, Request for Comments 3261: session initiation protocol. 2002. [3] LEOPOLDINO, Graciela Machado; MEDEIROS, Rosa C. Martins. H.323 – Um
padrão para sistemas de comunicação multimídia baseado em pacotes, 2001. RNP
News
Generation.
Disponível
em
. 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 . 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 . Acesso em 13 maio 2008.
79
[11] PAPAGEORGIOU, Pavlos. A comparison of H.323 vs SIP. University of Maryland at College Park, EUA. 2001. [12] PACKETIZER, H.323 versus SIP: a comparison. 2008. Disponível em . Acesso em 13 maio 2008.
80
