Voz sobre IP (VoIP) Marcel Barbosa de Oliveira, Marco Aurelio Goecking Santiago Ciência da Computação Universidade Federal Fluminense (UFF) Abstract. This paper describes a little bit of the VoIP tecnologie. VoIP tecnology is evoluating, especially by the difusion of the Internet.Other reason is the progress of the new network tecnologies.it will have a huge competition in the telecomunications market. VoIP has 2 types of protocols: the H. 323 standart gives some base for audio, video and data comunications through IP network and SIP is a protocol based on text that has the power of the Internet, as: HTTP format, DNS and the e-mail address style. Resumo. Este artigo descreve um pouco sobre a tecnologia de voz sobre IP. A tecnologia VoIP está evoluindo nos últimos anos, devido especialmente pela difusão da Internet. Mas não somente por isso, mas também pelo progresso das tecnologias de rede. Assim teremos uma grande competitividade no mercado. O VoIP tem 2 tipos de protocolos: H. 323 O padrão H.323 fornece uma base para comunicação de áudio, vídeo e dados através de uma rede baseada em IP, inclusive a Internet e o SIP é um protocolo baseado em texto que possui a força da Internet, fazendo uso de elementos comuns, tais como: o formato do HTTP, DNS e o estilo de endereçamento e-mail. 1. Introdução Nos dias de hoje, temos presenciado uma grande revolução acontecendo nas telecomunicações, resultante do incrível crescimento das redes baseadas em pacotes, especialmente pela Internet. Esta revolução está unificando os mundos de Dados e Telecomunicações em uma só rede convergente ubiqüa. Esta mudança não se trata apenas de um movimento do mercado, mas demonstra o progresso da tecnologia de rede. A telefonia baseada em redes de pacotes já dá passos concretos de maturidade, e muitos "Fornecedores de Telefonia IP" e "Serviços 0800 na Rede" estão sendo construídos dentro deste novo paradigma. A implementação de VoIP nos permite o tráfego de voz (exemplo, chamadas telefônicas e faxes) sobre uma rede IP. A proposta de convergência tornou-se tão interessante e importante para a manutenção da competitividade, que mesmo as operadoras telefônicas tradicionais estão se rendendo a esta tecnologia. E desenvolvendo soluções para racionalizar o uso de suas infraestruturas baseadas em circuitos fazendo a atualização para comutação de pacotes. Não
somente pelo apelo da redução de custos decorrentes da fusão de duas áreas, mas também pela possibilidade de prover uma melhor qualidade no transporte da voz, e ao mesmo tempo economizar em banda passante nacional e internacional. As principais causas para evolução do mercado de VoIP são as seguintes: o Baixo custo das chamadas telefônicas, o Serviços de valores agregados e mensagem unificada, o União da infra-estrutura de dados/voz. O sistema de VoIP consiste de um número de diferentes componentes: o Gateway/Media Gateway, o Gatekeeper, o Call Agent, o Media Gateway Controller, o Signaling Gateway, o Call Manager. O gateway converte a mídia por um tipo de rede para o formato requerido por um outro tipo de rede. O gateway também pode executar mensagens de áudio/vídeo e outras funções IVR, ou até mesmo executar conferência de mídia. No VoIP, o processador de sinal digital (DSP Digital Signaling Processor) segmenta o sinal de voz em quadros (frames) e os armazena em pacotes de voz. Estes pacotes de voz são transportados usando IP de acordo com uma das especificações para transmissão de multimídia (voz, vídeo, fax e dados) através da rede: o H.323 ITU o MGCP Level3, Bellcore, Cisco, Nortel o MEGACO/H2.48 IETF o SIP IETF o T.38 ITU Dois padrões principais disputam a hegemonia da Telefonia IP: ITU-T H.323 (International Telecommunications Union), presente em muitos dos equipamentos e softwares VOIP, e o SIP, proposto pela IETF (Internet Engineering Task Force), que, apesar do curto tempo do processo de padronização, tem mobilizado muitos fabricantes da área da telefonia e dados, por causa da sua flexibilidade, aderência com padrões genuinamente Internet e arquitetura aberta.
Os protocolos ITU-T H.323 e SIP serão descritos nas próximas sessões. 2. Arquitetura H.323 2.1 Introdução O padrão H.323 fornece uma base para comunicação de áudio, vídeo e dados através de uma rede baseada em IP, inclusive a Internet. O H.323 é um leque de recomendações da ITU que seta padrões para comunicação de multimídia sobre LANs (Local Area Networks) que não fornecem uma garantia de qualidade de serviço. Estas redes dominam o mercado desktops e incluem TCP/IP e IPX sobre as tecnologias de rede Ethernet, Fast Ethernet e Token Ring. Os padrões H.323 são importantes peças para um novo range de aplicações para multimídia baseadas em LAN. Isto inclui partes do H.225.0 RAS, Q.931/Q.932, H.245, RTP/RTCP e codecs de áudio/vídeo. 2.2 Elementos da Rede A arquitetura H.323 possui os seguintes elementos: Terminal Gateway Gatekeeper MCU 2.2.1 Terminal Um terminal ou um cliente, é um endpoint onde dados e sinalização H.323 se originam e terminam. Este pode ser um PC multimídia com aplicação H.323 ou um equipamento standalone (como um telefone IP conectado a uma porta USB). Um terminal deve suportar comunicação de áudio, enquanto o suporte a comunicação de vídeo e dados é opcional. 2.2.2 Gateway Um gateway fornece a tradução do formato dos dados, tradução de sinalização de controle, tradução de codecs de áudio e vídeo, e funcionalidade de call setup e terminação de chamada em ambos os lados da rede. 2.2.3 Gatekeeper Elemento opcional da rede H.323. São necessários para assegurar a confiabilidade e uma comunicação comercialmente viável. É comumente chamado de cérebro de uma rede H.323 por causa dos serviços de controle e gerenciamento centralizado que oferece. Quando existe um gatekeeper, todos os endpoints (terminais, gateways e MCUs) devem se registrar com ele. Mensagens de controle de registro de endpoints são roteadas através do gatekeeper. O gatekeeper e os endpoints por ele administrados formam um zona de gerenciamento. Serviços oferecidos pelo gatekeeper a todos os endpoints em sua zona:
Tradução de endereçamento O gatekeeper mantém uma base de dados para a tradução entre aliases, tais como números telefônicos internacionais e endereços de rede. Admissão e controle de acesso de endpoints Este controle pode ser baseado em disponibilidade de banda, limitação do número de chamadas H.323 simultâneas ou privilégios de registro de endpoints. Gerenciamento de banda Administradores de redes podem gerenciar a banda apenas especificando limitações no número de chamadas simultâneas e limitando a autorização de terminais específicos a realizar chamadas em horários específicos. Capacidade de roteamento Um gatekeeper pode rotear todas as chamadas originadas ou terminadas em sua zona. Esta capacidade fornece numerosas vantagens. Primeiro, informação de accouting das chamadas podem ser mantidas para cobrança e segurança. Segundo, um gatekeeper pode re-rotear uma chamada para um gateway apropriado baseado na banda disponível. Terceiro, re-roteamento pode ser usado para desenvolver vários serviços avançados, tais como: endereçamento móvel, call forwarding e voice mail. 2.3.4 MCU Multipoint Control Unit Uma MCU possibilita a conferência entre três ou mais endpoints. Consiste obrigatoriamente de uma controladora multiponto (MC) e zero ou mais processadores multipontos (MP). Apesar da MCU ser uma unidade lógica separada esta pode ser combinada dentro de um terminal, gateway ou gatekeeper. A MCU é um componente opcional de uma rede H.323. A controladora multiponto fornece uma localização centralizada para call setup multiponto. Sinalização de chamada e de controle são roteadas através da MC para que as capacidades dos endpoints possam ser determinadas e parâmetros de comunicação possam ser negociados. Uma MC também pode ser usada em uma chamada ponto-a-ponto que mais tarde pode ser extendida em uma conferência multiponto. O processador multiponto é responsável pela mixagem, chaveamento e processamento de áudio, vídio e dados entre os endpoints da conferência. A MCU é necessária em uma conferência multiponto centralizada onde cada terminal estabelece uma conexão ponto-a-ponto com a MCU. A MCU determina a capacidade de cada terminal e envia para cada um feixe de mídia mixado. No modelo de conferência descentralizada, uma MC assegura a compatibilidade da comunicação mas os feixes de mídia são multicast e a mixagem é realizada em cada terminal. 2.3 Conceitos dos Protocolos As mídias são transportadas pelos protocolos RTP/RTCP. O RTP transporta a mídia e RTCP transporta as informações de status e controle. A sinalização é transportada de forma confiável sobre TCP. Os seguintes protocolos lidam com a sinalização: RAS gerencia registro, admissão, status. Q.931 gerencia call setup e terminação.
H.245 negocia o uso de canais e a capacidade. Relação dos protocolos H.323 com o modelo OSI. 2.3.1 RTP / RTCP O RTP (Real-time Transport Protocol) fornece um conjunto de funções de transporte de rede fim-a-fim para aplicações transmitindo dados em tempo real, tais como: áudio, vídeo ou dados, sobre serviços de rede multicast ou unicast. RTP não garante qualidade de serviço para serviços em tempo real. O RTCP (Real-time Transport Control Protocol) é baseado na transmissão periódica de pacotes de controle para todos os participantes da sessão, usando o mesmo mecanismo de distribuição que usado no pacote de dados. O protocolo da camada inferior deve fornecer multiplexação de pacotes de dados e controle, por exemplo: usando portas UDP separadas.
O RTP e RTCP foram projetados para serem independentes das camadas de transporte e rede. 2.3.2 H225.0 RAS O canal RAS (Registration, Admission, Status) é usado para transportar mensagens usadas para descobrir o gatekeeper e processos de registros de endpoints que associa um endereço de um endpoint com seu endereço de transporte do canal de sinalização da chamada. O canal RAS é um canal não confiável. Já que as mensagens RAS são transmitidas em um canal não confiável, o H.225.0 recomenda contadores de timeout e retry para várias mensagens. Um endpoint ou gatekeeper que não pode responder a um pedido com o timeout específico deve usar a mensagem RIP (Request In Progress) para indicar que ainda está processando a solicitação. Um endpoint ou gatekeeper que recebe uma mensagem RIP deverá resetar os contadores de timeout e retry. No item Sinalização de Chamada será apresentada o procedimento H.225.0 com mais detalhes. 2.3.3 H.245 O H.245 é a linha de transmissão de outros sinais que não são de voz. Estes incluem capacidade de recepção e transmissão bem como o modo de preferência do ponto de recepção, canais lógicos de sinalização de controle e indicação. Procedimentos de confirmação de sinalização são especificados para assegurar comunicação de dados e audiovisual confiáveis. As mensagens H.245 são em sintax ASN1. Os tipos de mensagens podem ser definidos como request, response, command ou indication. O seguinte conjunto de mensagens estão disponíveis: Mensagem de determinação Master Slave Mensagem de capacidade de terminal Mensagem de sinalização de canal lógico Mensagem de sinalização de tabela de multiplexação Mensagem de Modo Request Mensagem de RTD (Round Trip Delay) Mensagem de Loop de manutenção Mensagens de Request e Responde de conferência TerminalID Commands e Indications 2.4 Sinalização da chamada Sinalização da chamada são as mensagens e procedimentos usados para estabelecer uma chamada, solicita mudanças na banda da chamada, recebe status dos endpoints da chamada e disconecta a chamada. Sinalização da chamada usa mensagens definidas na
H.225.0 e os procedimentos descritos no item Procedimentos de Sinalização de Chamada. 2.5 Canal RAS O canal RAS deverá ser usado para transportar mensagens usadas para descobrir gatekeeper e processo de registro de endpoints, já introduzido anteriormente. A seguir serão descritos estes dois processos. 2.5.1 Descoberta do gatekeeper A descoberta de um gatekeeper é o processo que um endpoint usa para determinar com qual Gatekeeper deverá se registrar. Este pode ser feito manualemte ou automaticamente. A descoberta manual não é padronizada. O método automático permite a associação do endpoint Gatekeeper a qualquer momento. O endpoint pode não conhecer quem é seu gatekeeper, ou pode ser necessário identificar outro gatekeeper devido a uma falha. O endpoint deverá enviar uma mensagem Gatekeeper Request (GRQ) multicast, perguntando Quem é meu Gatekeeper? Um ou mais gatekeepers podem responder com a mensagem Gatekeeper Confirmation (GCF) indicando Eu posso ser seu Gatekeeper, e retorna o Endereço de Transporte do canal RAS do gatekeeper. Se um gatekeeper não quer que um endpoint se registre, este deverá retornar uma mensagem Gatekeeper Reject (GRJ). Se mais de um gatekeeper responde, o endpoint deverá escolher qual gatekeeper quer usar. Descoberta Automática H.323 Endpoint Gatekeeper GRQ GCF/GRJ 2.5.2 Registro do endpoint Registro é o processo pelo qual um endpoint se junta a uma zona e informa ao gatekeeper do seu endereço de transporte e endereço associado. Como parte de seu processo de configuração, todos os endpoints deverão se registrar com o gatekeeper
descoberto. O registro deverá acontecer antes de que qualquer tentativa de uma chamada e pode acontecer periodicamente caso seja necessário. Um endpoint deverá enviar um Registration Request (RRQ) a um gatekeeper. Este é enviado ao endereço de transporte do canal RAS do gatekeeper. O gatekeeper deverá responder com um Registration Confirmation (RCF) ou um Registration Reject (RRJ). Um endpoint deverá se registrar com um único gatekeeper. Um endpoint poderá cancelar seu registro enviando uma mensagem Unregister Request (URQ) ao gatekeeper. O gatekeeper deverá responder com uma mensagem Unregister Confirmation (UCF). Isto permite ao endpoint mudar o endereço alias associado com o endereço de transporte, ou vice-versa. Se um endpoint não foi registrado com o gatekeeper, o mesmo deverá retornar uma mensagem Unregister Reject (URJ) ao endpoint. O gatekeeper também poderá cancelar o registro de um endpoint enviando uma mensagem URQ ao endpoint e o endpoint deverá responder com uma mensagem UCF. Registro H.323 Endpoint Gatekeeper RRQ RCF or RRJ URQ UCF/URJ Endpoint initiated iniciou Unregister Request Unregister Request URQ UCF Gatekeeper initiated iniciou Unregister Request Request 2.6 Canal de Sinalização da Chamada O canal de sinalização da chamada é usado para transportar mensagens de controle de chamada H.225.0. O canal de sinalização deve ser um canal confiável.
Em redes que não possuem um gatekeeper, as mensagens de sinalização da chamada são passadas diretamente entre os pontos chamador e chamado usando o Endereço de Transporte de Sinalização de Chamada. Nestas redes, é assumido qie o endpoint chamador conheça o Endereço de Transporte de Sinalização de Chamada do endpoint chamado e assim possam se comunicar diretamente. Nas redes que possuem um gatekeeper, é trocada a mensagem de admissão inicial entre o endpoint chamador e o gatekeeper usando o endereço de transporte do canal RAS do gatekeeper. Dentro das mensagens de adimissão trocadas, o gatekeeper indica na mensagem ACF se a sinalização da chamada será enviada diretamente ao outro endpoint ou ser será roteada pelo gatekeeper. No H.225.0 é especificado o uso obrigatório de mensagens Q.931 para a sinalização de chamada na H.323. 2.6.1 Canal de sinalização de chamada roteada Mensagens de sinalização de chamada poderão ser trocadas de duas maneiras. O primeiro método é o roteamento da sinalização de chamada pelo gatekeeper. Neste método, as mensagens de sinalização de chamada são roteadas através do gatekeeper entre os endpoints. Sinalização de Chamada Roteada pelo Gatekeeper Call Signalling Channel Messages RAS Channel Messages Gatekeeper Cloud 1 2 3 8 4 5 6 7 1 - ARQ 2 - ACF/ARJ 3 - Setup 4 - Setup 5 - ARQ 6 - ACF/ARJ 7 - Connect 8 - Connect Endpoint 1 Endpoint 2 O segundo método é a Sinalização de Chamada Diretamente entre Endpoints. Neste método as mensagens de sinalização de chamada são trocadas diretamente entre os endpoints. A escolha de qual método será usado é feita pelo gatekeeper.
Sinalização de Chamada Diretamente entre Endpoints Call Signalling Channel Messages RAS Channel Messages Gatekeeper Cloud 1 - ARQ 2 - ACF/ARJ 3 - Setup 4 - ARQ 5 - ACF/ARJ 6 - Connect 1 2 4 5 3 Endpoint 1 6 Endpoint 2 2.7.1 Roteamento do canal de controle Quando a sinalização de chamada roteada pelo gatekeeper é usada, existem dois métodos para rotear o canal de controle H.245. No primeiro método, o canal de controle H.245 é estabelecido diretamente entre os endpoints. Conexão Direta do Canal de Controle H.245 entre os Endpoints H.245 Control Channel Messages Call Signalling Channel Messages RAS Channel Messages Gatekeeper Cloud 1 2 3 8 4 5 6 7 1 - ARQ 2 - ACF/ARJ 3 - Setup 4 - Setup 5 - ARQ 6 - ACF/ARJ 7 - Connect 8 - Connect 9 - H.245 Channel 9 Endpoint 1 Endpoint 2
No segundo método, o canal de controle H.245 é roteado entre os endpoints através do gatekeeper. Este método permite que o gatekeeper redirecione o canal de controle H.245 para uma MC quando uma conferência ponto-a-ponto é trocada para uma conferência multiponto. Esta escolha é feita pelo gatekeeper. Quando é usada a Sinalização de Chamada Diretamente entre Endpoints, o canal de controle H.245 é obrigatoriamente diretamente conectado entre os endpoints. Conexão do Canal de Controle H.245 roteado através do Gatekeeper H.245 Control Channel Messages Call Signalling Channel Messages RAS Channel Messages Gatekeeper Cloud 1 2 3 8 9 4 5 6 7 10 1 - ARQ 2 - ACF/ARJ 3 - Setup 4 - Setup 5 - ARQ 6 - ACF/ARJ 7 - Connect 8 - Connect 9 - H.245 Channel 10 - H.245 Channel Endpoint 1 Endpoint 2 2.8 Procedimentos de sinalização de chamada O provisionamento da comunicação é realizada da seguinte maneira: 1) Call setup 2) Comunicação inicial e troca de capacidade 3) Estabelecimento de comunicação audio visual 4) Serviços de chamada 5) Terminação de chamada
2.8.1 Call Setup É realizada usando as mensagens de controle de chamada definidas no H.225.0 de acordo com uma série de procedimentos de controle de chamad, abaixo serão descrito dois procedimentos o call setup básico e call setup onde ambos os endpoints são registrados e a sinalização de chamada é roteada por ambos os gatekeepers. 2.8.1.1 Call Setup Básico Neste tipo de call setup, nenhum dos endpoints é registrado a um gatekeeper. Os dois endpoints se comunicam diretamente. O Endpoint 1 (chamador) envia a mensagem setup (1) para o conhecido identificador TSAP do canal de sinalização de chamada do Endpoint 2. O Endpoint 2 responde com a mensagem Connect (4) que contém o Endereço de Transporte do Canal de Controle H.245 para uso na sinalização H.245. Call Setup Básico, Sem Gatekeepers Endpoint 1 Endpoint 2 Setup(1) Call proceeding(2) Alerting(3) Connect(4) Call Signalling Messages 2.8.1.2 Call Setup Roteada Pelos Gatekeepers Neste tipo, ambos os endpoints são registrados por gatekeepers diferentes e ambos os gatekeepers escolheram rotear a sinalização da chamada. Endpoint 1 (chamador) inicia a troca de ARQ (1)/ACF (2) com o gatekeeper 1. O gatekeeper 1 retorna o Endereço de Transporte do Canal de Sinalização da Chamada dele mesmo na ACF (2). Então, o Endpoint 1 envia a mensagem de Setup (3) usando aquele Endereço de Transporte. Então, o gatekeeper 1 envia a mensagem de Setup (4) para o Endereço de Transporte do Canal de
Sinalização da Chamada conhecido do Endpoint 2. Se o Endpoint 2 deseja aceitar a chamada, este inicia a troca de ARQ (6)/ACF (7) com o gatekeeper 2. Se aceitável, o gatekeeper 2 retornará seu Endereço de Transporte do Canal de Sinalização da Chamada na ARJ (7) com o código de causa de routecalltogatekeeper. O Endpoint 2 responde ao Gatekeeper 1 com uma mensagem Facility (8) contento o Endereço de Transporte de Sinalização da Chamada do Gatekeeper 2. Então, o Gatekeeper 1 envia a mensagem de Release Complete (9) ao Endpoint 2. O Gatekeeper 1 envia a mensagem de Setup (10) para o Endereço de Transporte do Canal de Sinalização da Chamada do Gatekeeper 2. O Gatekeeper 2 envia mensagem de Setup (11) ao Endpoint 2. O Endpoint 2 inicia a troca de ARQ (12)/ACF (13) com o Gatekeeper 2. Então, o Endpoint 2 responde ao Gatekeeper 2 com a mensagem Connect (15) que contém seu Endereço de Transporte do Canal de Controle H.245 para uso da sinalização H.245. O Gatekeeper 2 envia a mensagem Connect (16) ao Gatekeeper 1 contendo o Endereço de Transporte do Canal de Controle H.245 do Endpoint 2, ou um Endereço de Transporte do Canal de Controle H.245 do Gatekeeper 2 (MC), baseado na escolha do Gatekeeper 2 do roteamento ou não do Canal de Controle H.245. O Gatekeeper 1 envia a mensagem de Connect (17) ao Endpoint 1 que deverá conter o Endereço de Transporte do Canal de Controle H.245 enviado pelo Gatekeeper2, ou um Endereço de Transporte do Canal de Controle H.245 do Gatekeeper 1 (MC), baseado na sua escolha do roteamento ou não do Canal de Controle H.245. Ambos Endpoints Registrados Sinalização de Chamada Roteada por Ambos os Gatekeepers Endpoint 1 Gatekeeper 1 Gatekeeper 2 Endpoint 2 ARQ(1) ACF(2) Setup(3) Call Proceeding(5) Setup(4) Call Proceeding(5) Facility(8) ARQ(6) ARJ(7) Release Complete(9) Setup(10) Call Proceeding(5) Setup(11) Call Proceeding(5) ARQ(12) Alerting(14) Connect(17) Alerting(14) Connect(16) ACF/ARJ(13) Alerting(14) Connect(15) RAS Messages Call Signalling Messages
2.9 Terminação da Chamada Qualquer Endpoint pode terminar a chamada seguindo os seguintes procedimentos: 1) Descontinuar a transmissão audio visual e então fechar todos os canais lógicos. 2) Transmitir a mensagem H.245 endsessioncommand no Canal de Controle H.245. 3) Esperar o recebimento da mensagem endsessioncommand do outro endpoint e então fechar o Canal de Controle H.245. 4) Enviar uma mensagem Release Complete para fechar o Canal de Sinalização de Chamada. 5) Usar os procedimentos abaixo para desconectar a chamada. 2.9.1 Terminação da Chamada Sem um Gatekeeper Em redes que não possuem um Gatekeeper, após os 4 passos acima descritos a chamada é terminada. Nenhum procedimento adcional é requerido. 2.9.2 Terminação da Chamada com um Gatekeeper Em redes que contém um Gatekeeper, o Gatekeeper precisa ter conhecimento do release da banda. Após a execução dos passos de 1 a 4 acima, cada endpoint transmite uma mensagem H.225.0 Disengage Request (DRQ) (3) para o Gatekeeper. O Gatekeeper responde com uma mensagem Disengage Confirm (DCF) (4). Neste ponto a chamada é terminada. A figura abaixo mostra o modelo da Chamada Direta, um procedimento similar é realizado para o modelo Roteado pelo Gatekeeper. As mensagens DRQ e DCF deverão ser enviadas no canal RAS. Terminação da Chamada Iniciada pelo Endpoint Gatekeeper 1 Endpoint 1 Endpoint 2 EndSessionCommand(1) Gatekeeper 2 EndSessionCommand(1) DRQ(3) DCF(4) Release Complete (2) DRQ(3) DCF(4) RAS messages Call Signalling messages H.245 messages Note: Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper.
2.9.3 Terminação da Chamada pelo Gatekeeper O gatekeeper pode terminar uma chamada enviando uma DRQ para um endpoint. O Endpoint imediatamente segue os passos de 1 a 4 e então responde ao Gatekeeper com uma DCF. O outro endpoint, recebendo endsessioncommand deve seguir os procedimentos descritos acima. A figura abaixo mostra o modelo de Chamada Direta, um procedimento similar é realizado para o modelo Roteado pelo Gatekeeper. Terminação de Chamada Iniciada pelo Gatekeeper Gatekeeper 1 Endpoint 1 Endpoint 2 Gatekeeper 2 DRQ(3) EndSessionCommand(1) EndSessionCommand(1) Release Complete (2) DCF(4) DRQ(3) DCF(4) RAS messages Call Signalling messages H.245 messages Note: Gatekeeper 1 and Gatekeeper 2 may be the same Gatekeeper. 3. SIP 3.1Introdução SIP (Session Initiation Protocol) é um protocolo baseado em texto que possui a força da Internet, fazendo uso de elementos comuns, tais como: o formato do HTTP, DNS e o estilo de endereçamento e-mail. SIP, geralmente, usa o SDP (Session Description Protocol) para especificar parâmetros da sessão. O SIP fornece os elementos dos protocolos necessários para fornecer serviços, tais como: call forwarding, call diversion etc. O endereço SIP (URL) pode ser usado em páginas web e pode então ser integrado como parte de poderosas aplicações, como por exemplo click-to-talk. O SIP possui um mecanismo próprio de segurança. Ele cria, modifica e termina sessões com um ou mais participantes. Estas sessões incluem conferências de multimída na
Internet, chamadas telefônicas via Internet e distribuição de multimídia. O SIP não está amarrado a nenhum protocolo de controle de conferências em particular. Este foi projetado para ser independente dos protocolos de transporte da camada inferior e pode ser extendido com capacidade adcional. SIP suporta 5 tipos de estabelecimento e terminação de comunicações de multimídia: User location User capabilities User availability Call setup Call handling. A operação do SIP é baseada em mensagens do tipo Request e Response. O modelo de básico de operação do SIP consiste em dois SIP UA (user agent) se comunicando diretamente. Onde os UAs podem ser telefones, aplicações ou gateways interfaceando a PSTN. O UA chamado pode aceitar o convite confirmando-o com uma resposta de OK. Finalmente, o UA chamador vai fechar loop com o UA chamado enviando de volta uma confirmação ao UA chamado. Operação Básica O Servidor SIP suporta telefonia baseada em SIP fornecendo um único ponto de acesso para clientes, mapeando nomes amigáveis em endereços, roteando mensagens de sinalização entre UAs e redirecionamento de chamadas. Existem dois tipos de servidores SIP, o Servidor Proxy e o Servidor Redirect. A operação do SIP depende do tipo de servidor usado. No modelo proxy, o servidor proxy SIP é o único ponto de contato que os UAs possuem para troca de mensagens de sinalização. No modelo de redirecionamento, o servidor redirect SIP deixa que o UA chamador conheça
a localização do UA chamado e então deixa que as mensagens de sinalização subsequentes sejam trocadas diretamente entre UAs chamador e chamado. No item Operação SIP estas operações serão melhor descritas. 3.2 Endereçamento Os endereços SIP, também chamados como SIP URL (Universal Resource Locator), existe na forma de users@hosts. Similar ao endereço de e-mail, uma SIP URL é identificado pelo user@host. A parte do endereço referente ao user pode ser um nome de usuário ou um número telefônico, e a parte do endereço referente ao host pode ser um nome de domínio ou endereço de rede. Voce pode identificar uma SIP URL do usuário através do seu endereço e-mail. 3.3 Protocolos SIP fornece os elementos básicos da telefonia: call setup e terminação, configuração da chamada e transferência de dados. Estes são alcançados usando SIP para a parte de call setup e terminação, SDP para descrição da configuração da chamada e RTP para transferência de dados. RTCP também é usado para o gerenciamento do transporte de dados. SIP pode ser executado sobre qualquer datagrama ou protocolo de transporte, tais como: UDP, TCP, ATM e Frame Relay. SIP é usualmente executado sobre TCP/IP por causa da conectividade amplamente difundida, serviços de diretórios, serviços de nomes e um ambiente de desenvolvimento mundialmente conhecido. O pacotes de áudio e vídeo são transportados usando o RTP sobre o UDP. As mensagens de sinalização da chamada SIP podem ser transportadas sobre UDP ou TCP, com o UDP sendo o método preferido devido a melhor performance a escalabilidade. Uma consideração importante quando estamos usando SIP sobre UDP é que a mensagem inteira deve ocupar um único pacote. Caso a mensagem SIP seja fragmentada em múltiplos datagramas, a probabilidade de perda de toda a mensagem aumenta com o número de fragmentos. Quando as mensagens SIP são transmitidas sobre WAN, as retransmissões que resultam da perda de fragmentos podem seriamente degradar a performance da sinalização da chamada. A porta padrão para SIP é 5060 embora qualquer porta disponível possa ser usada. A porta para ser usada pelo RTP/RTCP é especificada nas mensagens de sinalização da chamada SIP. Pilha de Protocolos SIP
3.4 SDP O SIP geralmente faz uso do SDP (Session Description Protocol) para descrever os atributos das sessões SIP. Os parâmetros SDP são encapsulados como corpo da mensagem de um request SIP. SDP executa uma regra similar àquela do H.245 no mundo H.323. Como o SIP, os cabeçalhos SDP são codificados em texto ASCII. O cabeçalho SDP são da forma <type>=<value>. O <type> (tipo) é sempre um único caracter e <value> (valor) é uma string texto cujo formato depende do <type>. O cabeçalho SDP especifica: Nome da sessão e propósito. Tempo que a sessão está ativa. A mídia que compreende a sessão. Endereço de transporte e formato da mídia da sessão. Largura de banda que será usada pela sessão. Informação de contato para a pessoa responsável pela sessão. 3.5 Mensagens SIP 3.5.1 Mensagens do tipo REQUEST: Invite - Inicia uma sessão. ACK - Confirma a resposta final a um INVITE. Bye - Termina uma sessão. Cancel - Cancela buscas e ringing. Options - Comunica features suportadas. Register - Registra um cliente com um serviço de localização. 3.5.2 Mensagens do tipo RESPONSE:
Indica tanto uma chamada em progresso ou uma informação de final de chamada. Este tipo de mensagem contém um Código-Status e uma Frase-Razão ou Categoria. O Código-Status é um número que indica o resultado de um request e a Categoria fornece uma descrição textual referente ao Código-Status. Código-status 1xx Progress 2xx Successful Request 3xx Redirection 4xx Incorrect Request 5xx Server Failure 6xx Global Failure Categoria 3.6 Operação SIP O SIP funciona da seguinte forma: Origem e destino são identificados por endereços SIP. Ao efetuar uma chamada SIP, o chamador primeiro localiza o servidor apropriado e então envia um request SIP. A operação mais comum é a INVITATION. Ao invés de alcançar diretamente o destino, um SIP request pode ser redirecionado ou pode desencadear um série de novos SIP requests pelos proxies. Usuários podem registrar suas localizações com servidores SIP. 3.7 Servidor Proxy O modelo de chamada proxy faz uso de um servidor proxy. Este servidor usa uma regra similar ao servidor proxy usado em um sistema HTTP. O servidor proxy roteia as mensagens de sinalização entre os UAs de destino e origem. Os pacotes RTP de áudio e/ou vídeo são enviados diretamente entre os UAs após o estabelecimento da chamada. 3.8 Servidor Redirector O servidor redirect SIP informa ao UA de origem a SIP URL do UA de destino. O UA de origem então procede com o setup da chamada diretamente com o UA de destino.
Operação com Servidor Proxy Operação com Servidor Redirect