Instituto Superior Técnico Redes com Integração de Serviços 4ª Parte Voz sobre IP 1 Introdução...3 2 Codificação da voz...4 3 Recomendação H.323...5 3.1 Arquitectura de H.323...6 3.2 Componentes do sistema...8 3.2.1 Terminais...8 3.2.2 Gateways...9 3.2.3 Gatekeepers...10 3.2.4 Unidades de Controle Multiponto MCU...11 3.3 Canais de Sinalização...11 3.3.1 Canal RAS...12 3.3.2 Canal de Sinalização de Chamada...15 3.3.3 Canal de Controlo H.245...22 3.3.4 Diagrama de estabelecimento e desligamento...25 4 Session Initiation Protocol (SIP)...26 4.1 Arquitectura básica...27 4.2 Endereçamento...28 4.3 Estrutura de Mensagens SIP...29 4.3.1 Cabeçalhos...30 4.4 Mensagens de Pedidos...31 4.4.1 REGISTER...32 4.4.2 INVITE...32 4.4.3 ACK...33 4.4.4 CANCEL...33 4.4.5 OPTIONS...33 1
4.4.6 BYE...33 4.5 Mensagens de Resposta...33 4.6 Sinalização...34 4.6.1 Chamada SIP directa...34 4.6.2 Chamada SIP com Servidor Proxy...35 4.6.3 Chamada SIP com Servidor Redirect...36 5 H323 versus SIP...38 6 Protocolos RTP/RTCP...39 6.1 Real-time Transport Protocol (RTP)...39 6.1.1 Cabeçalho RTP...40 6.1.2 Análise do funcionamento do RTP...42 6.2 Protocolo RTCP...43 6.2.1 Pacotes RTCP...44 6.2.2 Análise do funcionamento do RTCP...47 6.3 Requisitos de largura de banda de VoIP...48 6.3.1 Compressed Real Time Protocol (crtp)...49 6.3.2 Fragmentação e interpolação de pacotes...50 7 Cenários...52 7.1 PC a PC sobre IP...52 7.2 PC a Telefone sobre IP...53 7.3 Telefone a Telefone sobre IP...54 7.4 Integração Telefone / WEB sobre IP...55 7.5 Gateways de interligação entre PSTN e Internet...56 7.6 Interligação de Filiais sobre IP...57 8 Referências...58 9 Glossário...59 2
1 Introdução Voz sobre IP é a designação usual do serviço de conversação telefónica suportado numa rede de dados baseada em IP, em geral abreviada para VoIP (Voice over IP). Ao contrário das chamadas telefónicas tradicionais de comutação de circuitos, em VoIP as conexões telefónicas são baseadas em comutação de pacotes, pelo que a informação de voz tem de ser agrupada em blocos de informação de modo a ser transportada pela rede. Numa chamada VoIP os diferentes tipos de sinalização áudio de estabelecimento da chamada têm de ser simulados, nomeadamente o tom de chamar, corrente de chamar e tom de ocupado. Na fase de conversação a voz tem de ser convertida de analógico para digital, agrupada em pacotes, enviada através da rede, reagrupada na recepção e convertida de novo em analógico, através de Codecs. São seis as fases de uma chamada VoIP: 1) O terminal chamador levanta o auscultador do telefone e ouve o tom de chamar 2) O chamador introduz o número de telefone do destinatário, a partir do qual se obtém o endereço IP do destinatário 3) São activados os protocolos de estabelecimento de chamada para localizar o destinatário e enviar um sinal que produza um toque de chamada 4) O telefone do destinatário toca, indicando ao chamado que chegou uma chamada 5) O chamado levanta o auscultador e começa uma conversação bidireccional. O sinal de audio é codificado através de um Codec e enviado pela rede IP usando um protocolo de corrente (streaming) de voz. 6) A conversação termina com a colocação do auscultador no descanso, ocorrendo a terminação de chamada e consequente registo de facturação da mesma. Para além de diversas soluções proprietárias, existem actua lmente duas recomendações de voz sobre IP, uma do ITU-T e outra do IETF. A primeira recomendação do ITU-T surgiu em 1996 com a designação H.323, Visual telephone systems and equipment for local area networks which provide a nonguaranteed quality of service. Em Janeiro de 1998 surge a segunda versão da recomendação H.323, Packet Based Multimédia Communication Systems. A terceira versão foi aprovada em Setembro de 1999 e a quarta em Novembro de 2000. A solução do IETF denominada SIP Session Initiation Protocol encontra-se descrita no IETF RFC 2543 de Março de 1999. Relativamente a estas duas recomendações, o H.323 encontra-se actualmente mais implementado no mercado, provavelmente por ter surgido primeiro. No entanto, as características do SIP, principalmente a sua maior simplicidade comparativamente ao H.323, e o facto de ter sido desenvolvido com base no HTTP, colocam-no numa posição de concorrência efectiva com o H.323, apesar de esta disponibilizar mais características e ser mais completo no suporte a comunicações multimédia em redes de dados. 3
2 Codificação da voz A codificação da voz é feita em dispositivos designados CODEC (Coder/decoder), os quais para além de converterem os sons analógicos em digitais e vice-versa, em geral também efectuam compressão/descompressão do sinal degital, de modo a reduzir o débito final do sinal codificado. Indicam-se alguns dos CODEC mais usados actualmente, indicando-se a técnica de codificação utilizada, o ritmo binário gerado, o atraso de empacotamento e a qualidade da voz medida através do parâmetro MOS (Mean Opinion Score). O MOS é obtido através de testes, em que um conjunto de ouvintes avaliam a qualidade da voz numa escala de 1 (baixo) a 5 (alto). Codec Técnica de compressão Ritmo (kbps) Atraso de codificação (ms) Linear Linear - Sem compressão 128 0,125 4,5 G.711u/A PCM - Pulse Code Modulation 64 0,125 4,1 MOS G.726-32 ADPCM - Adaptive Diferencial PCM (16, 24, 32 40 Kbps) G.728 LD-CELP - Low-Delay Code-Excited Linear- Prediction 32 0,125 3,8 16 3-5 3,6 G.729A CS-ACELP - Conjugate-Structure Algebraic-Code-Excited Linear- Prediction 8 25 3,3 G.723.1 MP-MLQ 6.3 67.5 3,6 G.723.1 ACELP - Algebraic-Code-Excited Linear- Prediction 5.3 67.5 3,1? Tabela 2.1 Tipos de Codecs Como se pode observar, os Codecs de baixo débito como o G.729A e o G.723.1 utilizam uma reduzida largura de banda, mas em contrapartida têm uma menor qualidade, traduzida por valores mais baixos de MOS e apresentam tempos de codificação mais elevados. 4
3 Recomendação H.323 A recomendação H.323 especifica os requisitos técnicos para sistemas de comunicações multimédia sobre suportes baseados em redes de pacotes que não garantem qualidade de serviço. A estrutura de suporte à comunicação pode variar desde uma simples rede local até um conjunto de redes diferentes num ambiente de internetworking. As redes de pacotes abrangidas englobam redes de área local LAN, redes privadas, redes privadas interligadas do tipo campus LAN, redes metropolitanas MAN, redes WAN, ligações através de linha telefónica (Dial-up Connections), e ligações ponto-a-ponto. A interface com a rede, a rede física, e o protocolo de transporte, encontram-se fora do âmbito desta recomendação. O H.323 baseia-se num conjunto de recomendações do ITU-T que definem procedimentos e protocolos para comunicações multimédia na Internet. Este protocolo é fortemente baseado nos antecessores H.320 para Redes Digitais com Integração de Serviços (RDIS) e H.321 para B-RDIS. As operações básicas do protocolo são versões simplificadas do protocolo de sinalização Q.931 de RDIS. A recomendação H.323 baseia-se num conjunto de protocolos que servem diferentes requisitos e cooperam entre si, que se resumem na tabela seguinte. Protocolo Descrição H.323 Responsável pelas especificações do sistema H.225.0 Exerce funções de controlo de chamada (RAS), estabelecimento de chamada (semelhante ao Q.931) e sincronização dos dados H.235 Protocolo de segurança (autenticação, integridade, privacidade, etc.) H.245 Responsável pela comunicação das capacidades dos terminais H.450 Responsável por serviços suplementares (p. ex. chamada em espera, transferência de chamadas, etc.) H.246 Para interoperação com serviços de comutação de circuitos H.332 Para o estabelecimento de conferências de grande dimensão H.26x G.7xx Vídeo codecs (p. ex. H.261 e H.263) Áudio codecs (p.ex. G.711, G.723, G.729, G.728, etc.) Tabela 3.1 Protocolos H.323 Na Figura 3.1 apresenta-se um diagrama dos protocolos de H.323, situados em relação ao modelo OSI. 5
3.1 Arquitectura de H.323 Figura 3.1 - Protocolos H.323 A arquitectura de um sistema H.323 pode ser analisada a dois níveis, um onde se representam apenas as entidades endereçáveis, e um outro onde se representam todas as entidades. Na Figura 3.2 apresenta-se uma esquematização de todas as entidades endereçáveis, ilustrando-se também o conceito de zona e a interligação através de uma gateway com equipamentos terminais de outras recomendações ITU-T existentes em outros tipos de redes. 6
Terminal H.323 MCU H.323 Zona Rede de Pacotes Gatekeeper H.323 Gateway H.323 Terminal H.323 Terminal H.323 GSTN N-ISDN B-ISDN Terminal H.324 Terminal Voz Terminal H.320 Terminal H.321 Figura 3.2 Arquitectura de um sistema H.323 Definem-se em seguida alguns dos conceitos existentes no contexto desta recomendação. Define-se Zona como um conjunto de terminais, gateways, e MCUs, controlados por uma única gatekeeper. As Entidades (Entity) representam um componente, podendo ser classificadas em três tipos: - Entidades Endereçáveis (Addressable): as que possuem um endereço de transporte. - Entidades Chamáveis (Callable): as que podem ser utilizadas como destinatárias numa chamada. - Entidades Terminais (Endpoint): as que podem ser emissoras ou destinatárias de informação de utilizador. Todas as entidades podem ser dos três tipos excepto a Gateway, que só pode ser endereçável. Os Endereços de Rede (Network Addresses) utilizam-se para identificar entidades endereçáveis na interface de nível rede, existindo pelo menos um endereço para cada uma. Os Identificadores de Nível Transporte (TSAP Identifiers Transport Service Access Point Identifiers) permitem identificar entidades endereçáveis através de portos universalmente conhecidos (Well-Known Ports), permitindo ainda a utilização de vários canais de informação num único endereço de rede. Salienta-se a diferença entre Endpoints e Gatekeepers. Os Endpoints possuem apenas um identificador universalmente conhecido utilizado na sinalização de chamada. As Gatekeepers 7
possuem dois identificadores universalmente conhecidos, um que identifica uma gatekeeper individualmente e outro que define um canal de multicast para as Gatekeepers. O Endereço de Transporte (Transport Address) é constituído pelo conjunto de um endereço de rede e um TSAP Identifier. Os Endereços Alias (Alias Addresses) permitem a identificação de um Endpoint ou de uma conferência através de nomes, como por exemplo, endereços de correio electrónico, número de telefone, ou um identificador H.323 que consiste numa sequência de caracteres. Só se podem utilizar endereços alias dentro de uma zona controlada por uma gatekeeper, uma vez que é esta que tem como tarefa a conversão de endereços alias para endereços de transporte. 3.2 Componentes do sistema Na H.323 estão definidos os seguintes componentes ou entidades:?? Terminais;?? Gateways (GW);?? Gatekeepers (GK);?? Unidades de Controlo Multiponto (Multipoint Control Unit MCU). De seguida apresenta-se uma descrição dos diferentes componentes referidos. 3.2.1 Terminais Permitem estabelecer comunicações bidireccionais com outros terminais, com gateways, ou com MCUs. Estas comunicações envolvem obrigatoriamente informação de controle e áudio, podendo ainda incluir vídeo e/ou dados. Na Figura 3.3 apresenta-se o diagrama de blocos de um equipamento terminal H.323. Os Terminais são os pontos de comunicação do cliente numa rede IP e deverão suportar a seguintes funções:?? Sinalização e Controlo: O H.323 deverá suportar o H.245 para a comunicação das capacidades dos terminais, em adição ao H.225 utilizado para sinalização e estabelecimento de chamadas.?? Comunicação em tempo real: Os terminais devem suportar o protocolo RTP/RTCP, para comunicação de áudio e vídeo em tempo real.?? Codecs: Os terminais deverão suportar codecs para a codificação (na emissão) e descodificação (na recepção) dos sinais áudio/vídeo. 8
3.2.2 Gateways Figura 3.3 - Equipamento terminal H.323 Possibilitam comunicações bidireccionais de tempo real entre terminais H.323 e terminais de outras recomendações do ITU, ou então entre terminais H.323 e outras gateways H.323. Os terminais previstos encontram-se descritos nas recomendações: H.310; H.320; H.321; H.322; H.324; V.70. Os Gateways proporcionam a ligação entre a rede de comutação de pacotes e a rede de comutação de circuitos (GSTN), ambas podem ser públicas ou privadas. Os Gateways não são necessários quando não existe ligação a outras redes. Os Gateways são responsáveis por traduzir os formatos da transmissão e os procedimentos de comunicação. Nalguns casos têm ainda a capacidade de conversão entre diferentes codecs. Na Figura 3.4 apresentam-se diferentes configurações de Gateway H.323. 9
Figura 3.4 - Configurações de Gateway H.323 3.2.3 Gatekeepers É o componente de controle de uma determinada zona, efectuando dois tipos de serviços, a tradução de endereços, e o controle de acessos à zona, sendo esta definida como um conjunto de componentes H.323 existentes numa rede ou num conjunto de redes interligadas, com a particularidade de serem todos controlados pela mesma gatekeeper. As gatekeepers podem ainda disponibilizar serviços extra, como por exemplo, a gestão de largura de banda dos terminais, das gateways, e dos MCUs, ou a localização de gateways. Os Gatekeepers são opcionais no sistema H.323, mas quando presentes devem ter registados os equipamentos terminais associados. As funções que podem desempenhar são as seguintes:?? Tradução de endereços: de alias e números de telefone para endereços de transporte (no casos da rede IP o endereço de transporte é constituído pela combinação do endereço IP e do porto TCP ou UDP)?? Controlo da largura de banda?? Controlo da sinalização das chamadas?? Gestão de chamadas 10
3.2.4 Unidades de Controle Multiponto MCU É composto por um MC e por zero ou mais MPs. A sua função é possibilitar a comunicação em conferência multiponto entre três ou mais terminais e/ou gateways. Os MCU são o ponto de suporte entre três ou mais utilizadores. Estes são constituídos por duas componentes:?? Controladores Multiponto (Multipoint Controler - MC): Controlam as comunicações entre dois ou mais terminais intervenientes numa conferência. Realiza funções de controlo como a negociação e determinação entre terminais das capacidades de áudio/vídeo.?? Processadores Multiponto (Multipoint Processor - MP): São controlados por um MC e são responsáveis pelo processamento da informação do áudio, vídeo, e/ou os dados de uma conferência multiponto, de uma forma centralizada, efectuando operações de mistura, comutação, ou outro tipo de processamento sobre a informação. 3.3 Canais de Sinalização O H.323 utiliza vários canais para estruturar a troca de informação na comunicação. Um canal é uma ligação ao nível da camada de transporte, que pode ser uni- ou bi-direcional. No caso do H.323 estão definidos os seguintes canais: 1. Canal RAS: Canal de comunicação entre o utilizador e o seu gatekeeper. O protocolo do RAS (Registration, Admission e Status) é especificado pelo H.225.0. É por este canal que o utilizador se regista no gatekeeper e pede autorização para dar inicio a uma chamada. Se esta permissão for concedida o gatekeeper retorna o endereço de transporte do canal de sinalização da chamada (Call Signaling Channel) do destinatário. 2. Canal de Sinalização de Chamada (Call Signalling Channel): Este canal transporta informação para a sinalização de chamada. O protocolo utilizado neste canal é baseado no Q.931 e está especificado no H.225.0 e H.450.x. Quando a chamada é estabelecida o endereço de transporte do canal de controlo H.245 (H.245 Control Channel), é notificado por este canal. 3. Canal de Controlo H.245 (H.245 Control Channel: Este canal transporta as mensagens do protocolo H.245 acerca das capacidades dos terminais da comunicação. Uma vez conhecidos os parâmetros necessários são abertos os canais lógicos (Logical Channels) para a troca de dados. 4. Canais Lógicos para Media (Logical Channel for Media): Estes canais transportam áudio e vídeo. Cada tipo de informação é transportado em pares de canais (um para cada direcção unidirecionais separados, utilizando para tal os protocolos RTP e RTCP. 11
Na Figura 3.5 apresenta-se um diagrama simplificado das diferentes fases de estabelecimento de uma chamada H.323 entre dois endpoints. Figura 3.5 Fases de estabelecimento de chamada H.323 entre endpoints 3.3.1 Canal RAS O canal de comunicação entre endpoints e gatekeepers denomina-se Registration, Admission and Status (RAS) e utiliza um serviço sem ligação através do protocolo de transporte UDP constituído por um endereço de rede da respectiva gatekeeper e um porto universalmente conhecido que é 1719. Este canal dispõe ainda de um outro porto, também universalmente conhecido (1718) e de um endereço de multicast, o 224.0.1.41, ambos destinados à descoberta de gatekeepers. Está definido um conjunto de procedimentos entre endpoints e gatekeepers através do canal RAS, que se distribuem por várias fases e que são os seguintes: 1. Procura automática de gatekeeper (Automatic Gatekeeper Discovery); 2. Registo de um endpoint (Endpoint Registration); 3. Desregisto de um endpoint (Endpoint Unregistration); 12
4. Localização de um endpoint ( Endpoint Location ); 5. Pedido de admissão à rede (Endpoint Admission to Network). 3.3.1.1 Procura automática de gatekeeper Um endpoint pode sondar a existência de gatekeepers através do canal RAS utilizando o endereço de multicast 224.0.1.41, ou então utilizar o porto universalmente conhecido associado a este processo para saber se uma determinada gatekeeper está disponível. As comunicações neste canal utilizam o protocolo UDP. A mensagem destinada a este fim denomina-se Gatekeeper Request (GRQ), e é enviada por um endpoint. Como resposta, a/as gatekeeper/s pode/m responder com uma mensagem Gatekeeper Confirm (GCF) no caso de esta se encontrar disponível para controlar o endpoint, ou então pode/m responder com uma mensagem Gatekeeper Reject (GRJ) caso não possa assumir as funções de controladora do endpoint, enviando neste segundo caso a razão para a rejeição. A Figura 3.6 ilustra as mensagens trocadas neste processo. Endpoint Gatekeeper GRQ GCF ou GRJ Figura 3.6 Processo de Gatekeeper Discovery A resposta poderá ser de uma ou de várias gatekeepers, consoante se utilizar o porto universalmente conhecido juntamente com um endereço de rede de uma gatekeeper ou se utilizar o endereço de multicast juntamente com o porto universalmente conhecido. 3.3.1.2 Registo de um endpoint Um endpoint regista-se numa gatekeeper enviando uma mensagem Registration Request (RRQ) onde indica o seu endereço de rede e um conjunto de endereços alias pelos quais o endpoint pretende ser conhecido. Se a gatekeeper aceitar o pedido de registo responde com uma mensagem Registration Confirm (RCF) e actualiza a sua base de dados de tradução de endereços onde associa endereços de rede com endereços alias. No caso da gatekeeper não aceitar o pedido de registo envia uma mensagem Registration Reject (RRJ). Endpoint Gatekeeper RRQ RCF ou RRJ Figura 3.7 Processo de Registo de um endpoint 13
3.3.1.3 Desregisto de um endpoint Este processo permite a um endpoint terminar uma relação com uma gatekeeper, sendo iniciado através de uma mensagem Unregister Request (URQ), à qual a gatekeeper deve responder com um Unregister Confirm (UCF). A gatekeeper pode responder com um Unregister Reject (URJ) no caso de o endpoint não se encontrar registado na gatekeeper. Este processo pode ainda ser iniciado pela gatekeeper. Faz-se notar que o processo de Desregisto, permite a um endpoint redefinir os seus alias. A Endpoint Gatekeeper Endpoint Gatekeeper URQ URQ UCF ou URJ UCF Figura 3.8 ilustra este processo, iniciado pelo endpoint e pela gatekeeper, respectivamente. Endpoint Gatekeeper Endpoint Gatekeeper URQ URQ UCF ou URJ UCF Figura 3.8 - Desregisto iniciado pelo endpoint (esquerda) ou pela gatekeeper (direita) 3.3.1.4 Localização de um endpoint Este processo permite a um endpoint tentar localizar um outro endpoint através dos endereços de alias deste, enviando uma mensagem Location Request (LRQ) para o porto universalmente conhecido 1718 de uma gatekeeper. A gatekeeper irá comparar os endereços de alias recebidos no LRQ com os que detém na sua tabela de tradução de endereços e em caso positivo retorna uma mensagem Location Confirm (LCF) com o endereço de transporte do respectivo endpoint, no campo callsignaladdress. Caso contrário envia uma mensagem Location Reject (LRJ). Este processo pode ainda efectuar-se utilizando o endereço de multicast 224.0.1.41. Neste caso, todas as gatekeepers que recebam o LRQ verificam o pedido e respondem 14
apenas no caso positivo. Assim, não haverá resposta se não encontrarem nenhum dos alias contidos no LRQ na sua tabela de tradução de endereços. A Figura 3.9 ilustra este processo. Endpoint Gatekeeper LRQ LCF ou LRJ Figura 3.9 Processo de Localização de um endpoint 3.3.1.5 Pedido de admissão à rede Um pedido de admissão à rede ocorre quando um endpoint registado numa gatekeeper pretende realizar uma chamada ou responder a uma chamada. O endpoint envia uma mensagem Admission Request (ARQ) à gatekeeper onde se encontra registado, indicando o modelo de chamada (que se explica à frente) pretendido e a largura de banda necessária à chamada. Neste caso, a gatekeeper verifica se o número máximo de chamadas ainda não foi atingido, se é possível reservar a largura de banda que o endpoint pretende, e se está de acordo com o modelo de chamada proposto pelo endpoint. No caso de a gatekeeper aceitar o pedido, envia uma mensagem Admission Confirm (ACF) ao endpoint indicando a largura de banda concedida e o modelo de chamada a utilizar, que podem ser ambos diferentes dos propostos na mensagem ARQ correspondente. Na situação em que a gatekeeper não pode aceitar a chamada responde com uma mensagem Admission Reject (ARJ). A Figura 3.10 ilustra este processo. Endpoint Gatekeeper ARQ ACF ou ARJ Figura 3.10 Processo de admissão à rede 3.3.2 Canal de Sinalização de Chamada O canal de sinalização de chamada (Call Signalling Channel)dos endpoints utiliza um serviço orientado à ligação através do protocolo de transporte TCP, identificado pelo Call Signalling Channel Transport Address que consiste num endereço de rede do respectivo endpoint e no porto universalmente conhecido destinado a esta sinalização que é o 1720. 15
A sinalização de chamada faz-se de acordo com os procedimentos descritos na recomendação H.323 em conjunto com a recomendação H.225.0 e envolve o estabelecimento de chamadas, o pedido de alteração de largura de banda de chamadas, a obtenção do estado actual de endpoints intervenientes em chamadas e a terminação de chamadas. As comunicações envolvidas na sinalização de chamada entre endpoints dividem-se em cinco fases:?? Estabelecimento de chamada (Call set-up);?? Comunicações iniciais e negociação de capacidades (Initial comunications and capability exchange);?? Estabelecimento de comunicações audiovisuais (Establishment of audiovisual comunications);?? Serviços de chamada (Call Services);?? Terminação de chamada (Call Termination). A forma como se desenvolvem as comunicações em qualquer das fases depende do cenário existente que pode variar ao longo do tempo, quer através da alteração de configurações, quer através da existência ou não de gatekeepers envolvidas e a definição de zonas, ou até mesmo através do surgimento de novos equipamentos. Existem dois modelos de chamada, que diferem no papel desempenhado pela gatekeeper:?? Gatekeeper de Encaminhamento (Gatekeeper-Routed) - a gatekeeper serve de intermediária de todas as mensagens trocadas entre os endpoints.?? Endpoint Directo (Direct Endpoint) - a gatekeeper apenas autoriza ou não a troca de mensagens, que se fazem directamente entre os endpoints. A fase de estabelecimento de chamada processa-se de acordo com os procedimentos descritos na recomendação H.323 respeitando as mensagens definidas na recomendação H.225.0. Basicamente, esta primeira fase das comunicações entre dois endpoints tem como objectivo iniciar a comunicação, sendo enviada uma mensagem Setup pelo endpoint chamador, e como resposta uma mensagem Connect pelo endpoint chamado. Esta última mensagem contém a informação necessária para a segunda fase, onde se negoceiam as capacidades dos endpoints para a comunicação de acordo com a recomendação H.245. Podem ainda ser trocadas outras mensagens, como por exemplo, Call Proceeding, Alerting, Facility, ou Release Complete. A tabela 3.2 apresenta-se resumidamente a utilização de cada uma das mensagens aqui enunciadas. 16
Mensagem Setup Call Proceeding Alerting Connect Facility Release Complete Utilização Indica a intenção de estabelecer uma chamada Indica que o pedido de estabelecimento de chamada foi iniciado e que não serão aceites mais chamadas até este processo ter sido concluído Indica que o destinatário do pedido de estabelecimento de chamada já foi notificado do mesmo Indica a aceitação dum pedido de estabelecimento de um chamada Indica que uma chamada recebida deve passar primeiro por uma gatekeeper; ou então que deve ser reencaminhada para um outro qualquer destino como uma MCU por exemplo Indica que uma chamada foi terminada Tabela 3.2 Mensagem de estabelecimento de chamada As mensagens Setup e Connect são essenciais nesta primeira fase. Contudo, se pelo menos um dos endpoints estiver registado então irão ser trocadas mensagens com a/as respectivas gatekeeper/s. Assim, perfilam-se os seguintes cenários: - nenhum dos endpoints está registado; - ambos os endpoints estão registados na mesma gatekeeper; - só o endpoint chamador está registado; só o endpoint chamado está registado; - ambos os endpoints estão registados em gatekeepers diferentes. Outro factor que condiciona as mensagens trocadas nesta fase é o modelo de chamada escolhido pelas gatekeepers envolvidas. Existem assim uma variedade de situações possíveis, das quais se apresentam algumas que se consideram elucidativas. Para uma referência completa pode consultar-se o ponto 8.1 da recomendação H.323. 17
3.3.2.1 Nenhum Endpoint registado O endpoint chamador envia uma mensagem Setup directamente através do Call Signalling Channel (endereço de rede respectivo e porto 1720) do endpoint chamado, que responde com uma mensagem Connect onde indica o endereço de transporte a utilizar na sinalização da segunda fase como canal de controle H.245. Podem ainda ser enviadas mensagens Call Proceeding e Alerting por parte deste. A Figura 3.11 ilustra as mensagens trocadas neste cenário. Endpoint Chamador Setup Endpoint Chamado Call Proceeding Alerting Connect Figura 3.11 Nenhum endpoint registado 3.3.2.2 Ambos os Endpoints registados na mesma Gatekeeper Neste cenário distinguem-se duas situações: uma em que a gatekeeper decide fazer o encaminhamento das mensagens de sinalização, escolhendo o modelo de chamada Gatekeeper Routed Call Signalling ; e outra em que a gatekeeper opta por permitir a sinalização de chamada directamente entre os endpoints, através do modelo Direct Call Signalling. 3.3.2.2.1 Routed Call Signalling No caso de a gatekeeper optar pelo modelo de chamada Gatekeeper Routed Call Signalling, o endpoint chamador envia uma mensagem ARQ à gatekeeper. Se esta aceitar o pedido de acesso à rede responde com um ACF, onde coloca um endereço seu de transporte para ser utilizado entre ela e o endpoint chamador na sinalização de chamada. Caso não aceite o pedido responde com uma mensagem ARJ, originando o fim da comunicação. O endpoint chamador ao receber um ACF, envia uma mensagem Setup para o endereço da gatekeeper recebido neste. A gatekeeper por sua vez reenvia o Setup recebido para o endpoint chamado. Este se aceitar a chamada envia uma mensagem ARQ à gatekeeper que no caso de aceitar este pedido de acesso à rede responde com um ACF, caso contrário envia uma mensagem ARJ à qual o endpoint chamado responde com o envio de uma mensagem Release Complete à gatekeeper, que irá depois enviar uma mensagem Release Complete ao endpoint chamador terminando a comunicação. 18
O endpoint chamado se receber um ACF da gatekeeper envia uma mensagem Connect para o endereço de transporte da gatekeeper do qual recebeu a mensagem Setup, onde indica um endereço seu de transporte destinado à sinalização de controle H.245. A gatekeeper reenvia este Connect para o endpoint chamador podendo ou não alterar o endereço destinado à sinalização de controle H.245 da segunda fase, dependendo se a gatekeeper pretender ou não efectuar encaminhamento do canal de controle H.245. A Figura 3.12 ilustra as mensagens trocadas neste cenário. Endpoint Chamador ARQ Gatekeeper Endpoint Chamado ACF Setup Call Proceeding Setup Call Proceeding ARQ ACF/ARJ Alerting Connect Alerting Connect Figura 3.12 Ambos endpoints registados na mesma gatekeeper, Routed Call Signalling 3.3.2.2.2 Direct Call Signalling Na situação de Direct Call Signalling o endpoint chamador envia uma mensagem ARQ à gatekeeper que no caso de aceitar o pedido de acesso à rede responde com um ACF onde coloca o endereço de transporte do endpoint chamado. O endpoint chamador por sua vez envia uma mensagem Setup para o endereço do endpoint chamado que lhe foi fornecido pela gatekeeper. O endpoint chamado no caso de aceitar a chamada pede autorização à gatekeeper para aceder à rede enviando-lhe uma mensagem ARQ. A gatekeeper se aceitar o pedido de acesso à rede por parte deste endpoint responde com uma mensagem ACF. No entanto, pode recusar o pedido enviando uma mensagem ARJ e nesta situação o endpoint chamado envia uma mensagem Release Complete ao endpoint chamador terminando a comunicação. Na situação em que o endpoint chamado recebe uma mensagem ACF da gatekeeper envia uma mensagem Connect ao endpoint chamador, onde coloca um endereço seu de transporte, a ser utilizado para sinalização na segunda fase como canal de controle H.245. Na figura 3.12 ilustram-se as mensagens trocadas neste cenário. Note-se que as mensagens Call Proceeding e Alerting têm um carácter opcional, pelo que não são referidas no texto explicativo destes vários cenários, apesar de se apresentarem nas figuras. 19
Endpoint Chamador ARQ Gatekeeper Endpoint Chamado ACF Setup Call Proceeding ARQ ACF/ARJ Alerting Connect Figura 3.13 Ambos os endpoints registados na mesma gatekeeper, Direct Call Signalling 3.3.2.3 Só o Endpoint chamador é que está registado Neste cenário descreve-se a situação em que a gatekeeper opta pelo modelo de chamada Direct Call Signalling, que se ilustra-se na figura 3.13. O endpoint chamador envia uma mesagem ARQ à gatekeeper que, caso permita este pedido de acesso, responde com uma mensagem ACF onde indica o endereço de transporte do endpoint chamado. O endpoint chamador envia uma mensagem Setup para esse endereço, ao que o endpoint chamado responde com uma mensagem Connect no caso de entender aceitar a chamada, caso contrário responde com uma mensagem Release Complete, terminando a comunicação. Endpoint Chamador ARQ ACF Gatekeeper Endpoint Chamado Setup Call Proceeding Alerting Connect Figura 3.14 Só o endpoint chamador está registado, Direct Call Signalling 20
3.3.2.4 Ambos os Endpoints registados em Gatekeepers diferentes Neste cenário podem distinguir-se quatro situações: uma em que ambas as gatekeepers decidem fazer encaminhamento das mensagens; outra em que ambas as gatekeepers decidem permitir a comunicação directa entre os endpoints; e mais duas situações em que as gatekeepers escolhem modelos de chamada diferentes. Descreve-se o caso em que a gatekeeper do endpoint chamador decide fazer encaminhamento e a gatekeeper do endpoint chamado permite escolhe o modelo directo. O endpoint chamador envia uma mensagem ARQ à sua gatekeeper que lhe retorna uma mensagem ACF contendo um endereço seu de transporte para sinalização de chamada, para o qual o endpoint chamador envia uma mensagem Setup. Esta gatekeeper reenvia a mensagem Setup ao endpoint chamado contendo um seu endereço de transporte também destinado à sinalização de chamada mas com este endpoint. O endpoint chamado se decidir aceitar a chamada envia uma mensagem à sua gatekeeper, que decidindo pelo modelo de chamada Direct Call Signalling responde com uma mensagem ACF, levando a que o endpoint chamado envie uma mensagem Connect para o endereço do qual tinha recebido a mensagem Setup (i.e., portanto para a gatekeeper do endpoint chamador). A gatekeeper do chamador reenvia este Connect para o endpoint chamador podendo ou não alterar o endereço destinado à sinalização de controle H.245 da segunda fase, consoante pretenda ou não efectuar encaminhamento do canal de controle H.245. A Figura 3.15 ilustra as mensagens trocadas neste cenário. Endpoint Chamador ARQ Gatekeeper do Endpoint Chamador Gatekeeper do Endpoint Chamado Endpoint Chamado ACF Setup Call Proceeding Setup Call Proceeding ARQ ACF/ARJ Alerting Alerting Connect Connect Figura 3.15 Endpoints registados em gatekeepers diferentes, respectivamente Routed e Direct 21
3.3.3 Canal de Controlo H.245 Este canal transporta as mensagens do protocolo H.245 acerca das capacidades dos terminais da comunicação. Uma vez conhecidos os parâmetros necessários são abertos os canais lógicos (Logical Channels) para a troca de dados. 3.3.3.1 Comunicação inicial e troca de capacidades A segunda fase das comunicações rege-se de acordo com a recomendação H.245. Esta fase destina-se à negociação das capacidades dos dois endpoints relativamente ao tipo e número de canais que conseguem estabelecer durante a chamada, e no caso de ambos os endpoints possuírem unidades de controle (MC) e pretenderem estabelecer comunicações bidireccionais, qual delas vai ficar activa durante a chamada. A negociação de capacidades consiste na troca de informação entre os dois endpoints até chegarem a um acordo acerca da melhor opção comum de comunicação. Cada um informa o outro das suas capacidades relativamente ao áudio, ao vídeo, e aos dados, indicando as recomendações que entende, e o número de canais de cada tipo que conseguem implementar simultaneamente. Esta negociação processa-se através da troca de mensagens TerminalCapabilitySet, que contêm uma tabela de descritores de capacidades capabilitydescriptors. Cada descritor de capacidades contém um número que o identifica e um conjunto de capacidades simultâneas simultaneouscapabilities. Cada capacidade simultânea é também um conjunto de uma ou mais capacidades alternativas alternativecapabilityset em que cada uma destas representa um canal que pode ser aberto na chamada, sendo o tipo de canal identificado pelas designações das alternativas possíveis. As alternativas são descritas através de um conjunto de uma ou mais recomendações identificando o formato dos dados que podem circular no canal respectivo. A tabela 3.3 exemplifica este esquema, que se descreve em seguida. Número de identificação do descritor Tabela de descritores de capacidades Capacidades simultâneas 0 { {H.261, H.263},{G.711, G.723.1, G.728} } 1 { {H.262},{G.711} } Tabela 3.3 Exemplo de tabela de descritores de capacidades No exemplo apresentado na tabela 3.3, o descritor 0 indica que o endpoint consegue estabelecer dois canais, sendo um de vídeo e outro de áudio. No canal de vídeo pode operar alternativamente uma das recomendações H.261 ou H.263, e no canal de áudio pode operar alternativamente uma das recomendações G.711, G.723.1 ou G.728. O descritor número 1 indica que o endpoint consegue estabelecer também dois canais, sendo também um de vídeo e outro de áudio, mas neste caso não há alternativas na escolha das recomendações, ou seja, o canal de vídeo utiliza a recomendação H.262 e o canal de áudio a recomendação G.711. 22
Na Figura 3.16 apresenta-se um exemplo de negociação de capacidades entre dois terminais. Terminal 1 Gatekeeper 1 Terminal Capability Set Terminal 2 Terminal Capability Set Acknowledge Terminal Capability Set Acknowledge Figura 3.16 - Negociação de capacidades entre terminais 3.3.3.2 Negociação do controlo das comunicações entre terminais A determinação de qual endpoint vai controlar as comunicações dos canais bidireccionais através da respectiva unidade de controle (MC) faz-se por via de um processo, designado por Determinação de Mestre e Escravo (Master Slave Determination) descrito na recomendação H.323 e respeitando as regras procedimentais da recomendação H.245. O processo consiste em cada um dos endpoints gerar um número aleatório e enviar ao outro, e o que gerar o número maior fica como Mestre. Em caso de empate o processo repete-se. Na Figura 3.17 apresenta-se um exemplo de negociação de controlo das comunicações entre dois terminais. Terminal 1 Gatekeeper 1 Master Slave Determination Terminal 2 Master Slave Determination Ackowledge Master Slave Determination Acknowledge Figura 3.17 - Negociação do controlo das comunicações entre terminais 3.3.3.3 Estabelecimento de Canais de Comunicação Audiovisuais Após a negociação de capacidades e a determinação de qual dos endpoints assume o papel de Mestre, estabelecem-se os canais destinados a suportar as comunicações acordadas. O estabelecimento destes canais efectua-se através do canal de controle H.245, sendo enviada uma mensagem OpenLogicalChannel por parte do endpoint chamador e uma mensagem OpenLogicalChannelAck como resposta de endpoint chamado. Faz-se notar que os canais de áudio e vídeo utilizam o protocolo UDP e os canais de dados o protocolo TCP. Na Figura 3.18 apresenta-se um exemplo de estabelecimento de canais de comunicação audiovisuais entre dois terminais. 23
Terminal 1 Gatekeeper 1 Open Logical Channel Terminal 2 Open Logical Channel Acknowledge Open Logical Channel Acknowledge Figura 3.18 - Negociação do estabelecimento de canais de comunicação audiovisuais entre terminais 3.3.3.4 Serviços de Chamada Descrevem-se seguidamente os serviços de alteração da largura de banda dos canais estabelecidos e o pedido de informação de estado dos endpoints. O controle da largura de banda ocupada por uma chamada é feito pela gatekeeper de acordo com o limite estabelecido na troca de mensagens ARQ/ACF com o endpoint. O valor acordado nesta fase das comunicações engloba todos os canais de áudio, vídeo e dados da chamada, e o endpoint pode variar o débito de informação dos canais que tem estabelecidos, desde que não ultrapasse o valor máximo acordado. Na Figura 3.19 apresenta-se um exemplo de pedido de alteração de largura de banda. Endpoint 1 Gatekeeper 1 Gatekeeper 2 Endpoint 2 BRQ BCF/BRJ FlowControlCommand BRQ BCF/BRJ CloseLogicalChannel OpenLogicalChannel OpenLogicalChAck Figura 3.19 - Negociação de pedido de alteração de largura de banda No caso de um endpoint pretender aumentar a sua largura de banda envia uma mensagem Bandwidth Change Request (BRQ) à sua gatekeeper. Se a gatekeeper aceitar o pedido retorna uma mensagem Bandwidth Change Confirm (BCF), caso contrário envia uma mensagem Bandwidth Change Reject (BRJ). Após obter autorização para aumentar a largura de banda por parte da gatekeeper, o canal em que se pretende aumentar a largura de banda é fechado e abre-se um novo canal com o novo 24
valor máximo de largura de banda. O fecho do canal efectua-se através da mensagem CloseLogicalChannel e a abertura do novo canal processa-se da forma normal. 3.3.4 Diagrama de estabelecimento e desligamento Para finalizar, apresenta-se na Figura 3.20 um diagrama com as várias fases de estabelecimento e de desligamento de chamada. Terminal 1 Gatekeeper Terminal 2 Admission Request RAS Admission Confirm H.225.0 Call Sign. Setup Call Proceeding Admission Request Admission Confirm RAS H.225.0 Call Sign. Alerting Connect Terminal Capability Set Terminal Capability Set Acknowledge Terminal Capability Set Acknowledge Master Slave Determination H.245 Control Master Slave Determination Ackowledge Master Slave Determination Acknowledge Open Logical Channel Open Logical Channel Acknowledge Open Logical Channel Acknowledge Media: RTP / RTCP Close Logical Channel H.245 Control Close Logical Channel Acknowledge End Session End Session H.225.0 Call Sign. Release Complete RAS Disengage Request Disengage Confirm Disengage Request Disengage Confirm Figura 3.20 - Diagrama de estabelecimento de e desligamento de chamada 25
4 Session Initiation Protocol (SIP) O protocolo Session Initiation Protocol (SIP) é utilizado para iniciar, modificar e terminar sessões. As aplicações actuais do SIP estão direccionadas para as sessões interactivas de multimédia, tais como chamadas telefónicas ou conferências multimédia, mas o SIP pode ser utilizado em sistemas de mensagens instantâneas, notificação de acontecimentos, ou na gestão de outros tipos de sessão como por exemplo jogos distribuídos. No estabelecimento de sessões, o SIP comporta-se como um protocolo de sinalização, oferecendo serviços similares aos protocolos de sinalização utilizados no serviço telefónico, como por exemplo o Q.931 ou o H.323, mas num contexto Internet. O SIP difere dos protocolos anteriormente utilizados na rede telefónica pelo facto de não fazer reserva de recursos, mas em contrapartida estende as suas funções para novos domínios. O SIP baseia-se em outros protocolos já conhecidos como é o caso do SMTP (Simple Mail Transfer Protocol) e HTTP (Hiper Text Transport Protocol). Tal como estes o SIP é um protocolo textual, baseado no sistema de cliente/servidor, em que o cliente elabora um pedido que é enviado ao servidor ao qual este ultimo responde. Um pedido evocará um método no servidor e este pode ser enviado sobre TCP ou UDP. O protocolo SIP faz parte de uma arquitectura de protocolos de Conferência Multimédia Internet, em desenvolvimento no IETF. Figura 4.1 apresenta-se a pilha de protocolos correspondente a esta arquitectura. Figura 4.1 - Arquitectura de protocolos de Conferência Multimédia Internet 26
4.1 Arquitectura básica Na arquitectura do SIP estão definidos os seguintes tipos de entidades:?? Agentes de utilizador (user agent)?? Entidades de registo (registrars)?? Servidores de proxy (proxy server)?? Servidores de redireccionamento (redirect server)?? Servidores de localização?? Gateways Agentes de utilizador São os responsáveis por iniciar os Pedidos, sendo também o seu destino final. Podemos distinguir dois tipos de agentes de utilizador: - Agentes de utilizador cliente: os que fazem Pedidos - Agentes de utilizador servidor: os que atendem Pedidos. Exemplos de agentes de utilizador são os telefones IP e aplicações de conferência, que em geral podem funcionar simultaneamente como clientes e como servidores. Entidades de registo São as responsáveis por saber onde se encontra um determinado utilizador dentro do seu domínio, sendo responsáveis por aceitar os Pedidos de registo (REGISTER). Servidores de proxy (proxy server) São programas intermédios (ao nível de aplicação) que funcionam ao mesmo tempo como servidores e clientes no intuito de fazer Pedidos em benefício de outros clientes. Os Pedidos são atendidos internamente ou encaminhados para outros servidores, possivelmente depois de serem traduzidos. Assim um proxy interpreta e se necessário rescreve uma mensagem de Pedido antes de a reenviar. Servidores de redireccionamento (redirect server) Aceitam um Pedido SIP, convertem o endereço em zero ou mais endereços novos, devolvendo esses endereços ao cliente. Ao contrário do servidores de proxy, o servidor de redireccionamento não inicia o seu próprio Pedido SIP e ao contrário dos agentes de utilizador servidores, não aceita chamadas. Servidores de localização Os servidores de proxy e de redireccionamento utilizam outros servidores denominados de servidores de localização para obter informação sobre a localização de um determinado chamado. No entanto, os servidores de localização não fazem parte da especificação SIP. 27
Gateway Uma Gateway SIP é uma entidade que serve de interface entre uma rede que implementa SIP e outra rede que utiliza outro protocolo de sinalização. Do ponto de vista do protocolo SIP a Gateway é apenas um tipo especial de Agente de Utilizador, onde este actua em representação de outro protocolo em vez de uma pessoa humana. Uma Gateway termina a sinalização SIP e pode igualmente terminar o caminho de dados de utilizador (aúdio, vídeo). Por exemplo, uma Gateway SIP H.323 termina a sinalização SIP e converte-a para H.323 mas a informação de media (áudio e vídeo) não necessita de ser alterada, podenso ser enviada directamente entre terminais sem ser necessário passar pela Gateway. Pelo contrário, uma Gateway SIP PSTN termina quer a sinalização quer a ligação de media. Na Figura 4.2 apresenta-se um diagrama genérico da arquitectura SIP. Figura 4.2 Exemplo de uma chamada SIP simples Como se pode verificar na figura anterior, numa chamada típica as mensagens SIP originadas no agente de utilizador atravessam um ou mais servidores de proxy SIP, alcançando um ou mais agentes de utilizador. A informação de media circula directamente entre agentes de utilizador. No entanto, os agentes de utilizador podem comunicar directamente entre si, sendo bastante comum que o primeiro Pedido se faça através da cadeia de proxies, seguindo os restantes directamente. 4.2 Endereçamento Para que exista uma localização e convite de participantes para uma sessão, terá de haver uma maneira do destinatário poder ser contactado. As entidades endereçadas pelo SIP são utilizadores em máquinas identificadas por um SIP URL. 28
Este SIP URL é semelhante a um identificador tradicional de email (utilizador@host), onde utilizador pode ser um nome ou um número de telefone e o host pode ser um domínio ou um endereço de rede numérico, por exemplo:?? sip:claudio@ist.utl.pt?? sip:eduardo@176.7.6.1 Quando um cliente quer enviar um pedido, terá de primeiro obter o endereço do destinatário. Se este consistir num endereço IP numérico o cliente contacta o servidor SIP no destino. Caso consista num domínio, o cliente através do DNS deverá obter o endereço IP onde o servidor se encontra. Uma vez localizado o servidor o pedido é enviado utilizando TCP ou UDP. Quando um servidor SIP recebe um pedido, terá de localizar o utilizador no seu domínio (que pode estar ligado a mais de uma máquina, ou mesmo a nenhuma). Para localizar o utilizador existe um servidor de localização externo, que quando inquirido, retorna a lista de localizações do utilizador. Esta localização pode ser registada dinamicamente no servidor SIP. Se o utilizador não for encontrado o servidor envia uma resposta ao cliente participando a situação. Se o utilizador for encontrado, a acção tomada depende do tipo de servidor utilizado:?? Proxy Server: O pedido é enviado para as localizações (em sequência ou paralelamente)?? Redirect Server: Envia resposta com a lista de localizações encontradas. O cliente poderá então contactar directamente para a localização do utilizador. 4.3 Estrutura de Mensagens SIP O SIP é um protocolo baseado no formato de texto. Uma mensagem SIP é constituída por várias linhas terminadas pelos caracteres CRLF, sendo a sintaxe das mensagens SIP e dos correspondentes campos de cabeçalho semelhantes ao HTTP/1.1. Uma mensagem SIP pode ser transportada por vários protocolos de comunicação ao atravessar diferentes proxies entre agentes de utilizador. No entanto, o modo de funcionamento do SIP recomenda a utilização do UDP, pois o TCP apresenta a desvantagem do atraso de estabelecimento de uma conexão e posterior desligamento. As mensagens SIP dividem-se em: - Pedidos, quando emitidos de um cliente para um servidor e - Respostas, quando emitidos de um servidor para um cliente. As mensagens SIP têm a seguinte constituição:?? Linha inicial (do tipo Request-Line ou Status-Line).?? Cabeçalho (dos tipos geral, pedido, resposta ou entidade)?? Uma linha separadora (apenas contendo os caracteres CRLF)?? Corpo da mensagem (opcional) 29
As mensagens SIP podem conter qualquer caracter, pois o protocolo foi desenhado de forma independente do conjunto de caracteres que poderá utilizar. Para que a sinalização seja mais segura podem ser utilizados mecanismos de cifra e autenticação. 4.3.1 Cabeçalhos As mensagens utilizam os cabeçalhos para especificar parâmetros como: emissor, destinatário, caminho, tipo e comprimento do corpo da mensagem, etc. Existem cabeçalhos que são utilizados em todas as mensagens, outros serão utilizados quando apropriado. Existem 37 cabeçalhos que podem ser divididos em quatro grupos diferentes:?? Genéricos: Utilizados quer nas mensagens de pedidos quer nas de resposta?? Entidades: Define informação acerca do corpo da mensagem?? Pedidos: Permite enviar informação adicional acerca do pedido ou do próprio cliente?? Respostas: Permite enviar informação adicional acerca da resposta Na Tabela 4-1 mostam-se alguns dos cabeçalhos fundamentais: Call-ID Contact Content length Content type From Require Subject Cseq To Via Identifica univocamente o registo do cliente Contém as localizações, utilizadas de acordo com a mensagem em causa Indica quantos bytes ocupa o corpo da mensagem Indica o tipo de informação que a mensagem contém Indica quem iniciou o pedido Utilizado pelos clientes para informar o agente de utilizador servidor, sobre opções que são necessárias para processar o pedido Indica a natureza da chamada (Command Sequence) Identifica univocamente um pedido dentro de uma chamada Especifica o receptor do pedido Indica o caminho percorrido pelo pedido Tabela 4-1 - Cabeçalhos SIP A utilização do campo de URI (Universal Resource Indicator) em simultâneo com o campo de cabeçalho To pode parecer uma redundância, mas não é, porque enquanto o URI pode ser alterado à medida que a mensagem progride ou é redireccionada, o valor do campo To mantém-se constante. 30
O campo de Call-Id identifica um determinado convite de um cliente, ou todos os Pedidos REGISTER de um determinado cliente. O campo de cabeçalho Contact permite que a comunicação entre o chamador e chamado passe a ser feita directamente, sem a intervenção dos servidores de proxy, depois de concluída a fase de estabelecimento da chamada. Um dos campos do cabeçalho de um Pedido que vai sendo actualizado à medida que o Pedido atravessa vários servidores de proxy é o campo de Via. Assim, sempre que um servidor reenvia um Pedido, ele deverá adicionar o seu endereço ao início da lista de encaminhadores no campo de Via. 4.4 Mensagens de Pedidos Na versão SIP 2.0 existem seis diferentes tipos de pedidos, designados igualmente de métodos:?? REGISTER: Método utilizado para indicar ao SIP Server, informação acerca da localização dos utilizadores.?? INVITE: Este método indica que o utilizador ou serviço são convidados a participar na sessão. O emissor indica o tipo de dados que está preparado para receber, assim como os seus parâmetros (p.ex. a rede de destino). Uma resposta de sucesso, envia no corpo da mensagem que tipo de dados o destinatário está preparado para receber.?? ACK: Confirma que o cliente recebeu uma reposta final a um INVITE. Este método só é utilizado com o método INVITE.?? CANCEL: Este método cancela um pedido pendente, não afectando contudo pedidos já completados (um pedido considera-se completado depois de receber uma resposta final).?? OPTIONS: Com este método podem ser solicitadas informações acerca de capacidades de ligação, contudo este método não estabelece ligação.?? BYE: O agente utilizador cliente utiliza este método para notificar o servidor que pretende desligar a chamada. A linha inicial de uma mensagem de Pedido corresponde a uma Request-Line e é composta de vários campos: Request-Line = Método URI Versão_SIP A Versão_SIP deverá neste caso indicar a versão 2 ("SIP/2.0"). Os URI do SIP começam com "sip:", como se exemplifica. sip:alice@example.com sip:+1-212-555-1212:1234@gateway.com;user=phone 31