UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES GUILHERME VOLTAN JÚNIOR DEZEMBRO

2 UNIVERSIDADE CATÓLICA DE GOIÁS DEPARTAMENTO DE COMPUTAÇÃO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Júnior à Universidade Católica de Goiás, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação aprovado em 22/06/2005 pela Banca Examinadora: Professor Cláudio Martins Garcia, MsC. UCG Orientador 2

3 VOZ SOBRE IP SEGURANÇA DE TRANSMISSÕES GUILHERME VOLTAN JÚNIOR Trabalho de Projeto Final de Curso apresentado por Guilherme Voltan Júnior à Universidade Católica de Goiás, como parte dos requisitos para obtenção do título de Bacharel em Ciência da Computação. Professor Cláudio Martins Garcia, MsC Orientador Professor José Luiz de Freitas Júnior, Dr. Coordenador de Projeto Final de Curso 3

4 Ao Professor Cláudio Martins Garcia, orientador acadêmico e amigo, pelo apoio e confiança depositada. Aos meus verdadeiros amigos pelo apoio e compreensão. A minha família goiana, pelo incentivo e a todos os que fizeram parte da minha vida, pois sem essas pessoas seria muito mais difícil sobreviver longe do manto protetor dos pais e irmão. 4

5 À Deus pela sua sabia orientação e por me ajudar a destacar em meio ao seu rebanho, ao Santo Expedito que em momentos difíceis me amparou, a Nossa Senhora Aparecida que em vários momentos sorriu para apoiar minha querida mamãe e as lágrimas de felicidades e saudades despejadas pelos meus familiares. 5

6 RESUMO Transmissões de voz sobre IP tiveram seus primeiros estudos nos anos setenta e de lá para cá vem apresentando grandiosos índices de melhoria. Hoje VoIP é conhecida mundialmente, pela sua economia em ligações telefônicas, que são fáceis de serem realizadas, precisa-se apenas de um terminal com acesso a rede mundial de computadores. As vantagens são inúmeras e as desvantagens, claro existem, porém minimizadas, hoje o que mais afeta a VoIP é a sua qualidade de serviço, porém isso para usuários que contam com uma largura de banda relativamente boa torna-se um tanto quanto imperceptível, porém existem outros problemas relativos a QoS que também à afetam, como é o caso do congestionamento, segurança e confiabilidade. Apesar de várias desvantagens estarem presentes na VoIP, ela apresenta a cada dia que passa um numero maior de adeptos e um crescimento tecnológico muito maior, o que pode levar as redes de telefonia tradicionais à extinção, já que a VoIP além de prestar todos os serviços prestados pela telefonia tradicional ainda tem a capacidade de oferecer muito mais serviços, porém devemos levar em consideração que o maior alvo da VoIP, as redes tradicionais, também são seu maior concorrente e isto se deve à sua alta disponibilidade e a sua viabilidade. Muitos estudos e protocolos fazem e fizeram da VoIP o que ela é hoje, e podemos citar parte dessa história através de vários componentes, entre eles, os protocolos de sinalização H.323 e o revolucionário SIP que parece estar tomando frente junto ás transmissões VoIP, o grandioso protocolo de transporte RTP que é usado praticamente em todas as operações de transmissões de voz, graças à sua qualidade na entrega de pacotes, e o RTCP que atua juntamente ao RTP provendo controle, entre vários outros, e é por causa de todo este apanhado histórico e pela vontade sobre a descoberta de novos meios de comunicação que a VoIP poderá em breve ser marco da história mundial. 6

7 ABSTRACT Transmissions of voice about IP had their first studies in the Seventies and since then they have presented huge indices of improvement. Today VoIP is known world-wide for its economy in telephone calls, that are easy to be carried through, it s used only a terminal with access to the world-wide net of computers. The advantages are innumerable and the disadvantages, however minimized, today what affects more the VoIP is its quality of service, however for some users who count on a width of relatively good band becomes imperceptible, nevertheless there are other problems related to the QoS that also affect it, such as the case of congestion, security and trustworthiness. Despite of some disadvantages presented in the VoIP, it presents each day a great number users and a very big technological growth, and due to this can jeopardize the telephone companies besides the VoIP has all the services done for the traditional telephone companies, still has the capacity to offer much more services, furthermore we must take in consideration that the target of the VoIP, the traditional companies are one of the strongest competitors because of their high availability and reliability. Many studies and protocols have helped the VoIP becomes what it is today, and we can explain part of this history through some components, such as, the protocols of H.323 transmissions and revolutionary SIP which is better together with VoIP transmissions, the huge protocol of transport RTP that has been practically used in all the operations of voice transmissions, thanks to its quality in the delivery of packages, and the RTCP that works together with the RTP providing, control and several others, and it s because of all this historical background and for the discovery of new medias that the VoIP will be able to become the landmark of worldwide history. 7

8 Sumário REDES DE TRANSMISSÃO DE VOZ SOBRE IP HISTÓRIA DO SURGIMENTO DAS REDES VOIP LIGAÇÃO TELEFÔNICA ATRAVÉS DE REDES IP VANTAGENS DA TRANSMISSÃO DE VOZ SOBRE IP ARQUITETURA DAS REDES VOIP SERVIÇOS DA REDE VOIP OBSTÁCULOS PARA CONSOLIDAÇÃO DA REDE VOIP PROTOCOLOS DE SINALIZAÇÃO H Introdução Histórica Componentes da Recomendação H Recomendação H.323 para a Arquitetura Protocolar do H Vantagens em se utilizar H Chamada H SIP Introdução Características Arquitetura do SIP Mensagens SIP Chamadas SIP COMPARAÇÃO ENTRE H.323 E SIP PROTOCOLO SDP PROTOCOLOS ENTRE GATEWAYS DE MÍDIA E CONTROLADORES DE MÍDIA 47 MGCP Comandos MGCP MEGACO Comandos MEGACO COMPARAÇÃO ENTRE MGCP E MEGACO PROTOCOLO RTP FUNCIONALIDADES DO RTP PACOTE RTP SESSÃO RTP QUALIDADE DE SERVIÇO MODELO BÁSICO DE QoS CONGESTIONAMENTO Fifo Fair Queueing Priority Queueing Custom Queueing Comparação entre os Métodos de Enfileiramento Detecção RED e WRED PROTOCOLO RTCP Funcionalidade do RTCP Pacote RTCP PROTOCOLO CRTP (Compressed Real-Time Protocol) PROTOCOLO IEEE 802.1p priority queueing

9 PROTOCOLO RSVP Mensagens RSVP PARÂMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoIP Atraso Eco Sobreposição do Locutor Jitter Perda de Pacotes SOLUÇÕES PARA GARANTIA DE QoS EM REDES IP Dejitter Buffer Classificar ou Identificar o Tráfego Enfileiramento, Priorização e Disciplina de Despacho SEGURANÇA EM REDES VOZ SOBRE IP Introdução Ameaças Captura de tráfego e acesso indevido a informações Código Malicioso Fraude Financeira, Uso indevido de recursos corporativos Repúdio Meios de proteção Segmentar o tráfego de voz e dados Controlar o acesso ao segmento de voz com um Firewall especializado Evitar o uso de aplicações de telefones para microcomputadores (PC-Based IP phones), utilizando preferencialmente telefones IP que suportem VLAN Usar endereços IP privativos e inválidos (compatíveis com RFC 1918) nos telefones IP Configurar os telefones IP com endereços IP estáticos, associados ao MAC Address Utilizar servidores DHCP separados para voz e dados Monitorar os endereços MAC no segmento de voz Implementar mecanismos que permitam autenticar os usuários dos telefones IP Implementar um sistema IDS Fazer o hardening do host onde está instalado o call manager Monitorar a performance e status dos serviços de VoIP Montar uma estrutura de Help Desk capacitada para dar suporte em VoIP Restringir o acesso físico Auditar o uso dos recursos Criptografar o tráfego de VoIP Conclusão Benefícios da Convergência Riscos e Inibidores da convergência SPIT em geral Origem e significado Prejuízos causados pelo spit Envio de spit SPIT (spam over IP Telephony), abordagem geral SEGURANÇA NOS PROTOCOLOS H.323 E SIP SIP Segurança na troca de mensagens Segurança da mídia Firewalls SIP H SNIFFERS VOIP

10 Características dos Sniffers VoIP EXEMPLO DE APLICAÇÃO DE SEGURANÇA EM REDES VOIP Encriptação de VoIP no sistema omnipcx enterprise Conclusão Conclusões Referências Bibliográficas

11 LISTA DE FIGURAS Fig. 1.1: Arquitetura de uma rede VoIP Fig. 1.2: Arquitetura Protocolar Fig. 1.3: Componentes do padrão H Fig. 1.4: Troca de mensagens entre entidades H Fig. 1.5: Arquitetura Protocolar do H Fig. 1.6: Padrão H Fig. 1.7: Fluxo básico da conexão H Fig. 1.8: Negociação de Capacidades H Fig.1.9: Abrindo canais lógicos Fig. 1.10: Conversação ativa H Fig. 1.11: Arquitetura Sip Fig. 1.12: O formato de mensagem SIP Fig. 1.13: O formato da mensagem de pedido SIP Fig. 1.14: O formato da resposta SIP Fig. 1.15: Chamada ponto-a-ponto SIP Fig. 1.16: Finalização de uma chamada SIP Fig. 1.17: Alteração de chamada SIP Fig. 1.18: Resposta busy here Fig. 1.19: Exemplo da utilização do SDP numa mensagem SIP Fig. 1.20: Arquitetura MGCP geral Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Solução Clarent Fig. 1.22: Arquitetura do MGCP Trunking Gateways Solução 51 MCI... Fig. 1.23: Comandos MGCP Fig. 2.1: Pacote RTP Fig. 3.1: Modelo para QoS Fig. 3.2: Operação da Fila FIFO Fig. 3.3: Filas Fair Queueing Fig. 3.4: Operação do Algoritmo WFQ Fig. 3.5: Filas WFQ Fig. 3.6: Operação do enfileiramento Priority Queueing Fig. 3.7: Filas Priority Queuening Fig. 3.8: Operação do enfileiramento Custom Queueing Fig. 3.9: Filas Custom Queueing Fig. 3.10: Funcionamento do WRED Fig. 3.11: Protocolo RTCP Fig. 3.12: Encapsulamento de pacote VoIP Fig. 3.13: Protocolo RSVP em Máquinas do Usuário e Roteadores Fig. 3.14: Camada de atuação do Protocolo RSVP Fig. 3.15: Transmissão e Recepção de pacotes Fig. 3.16: Atraso na formação de pacotes Fig. 3.17: Atraso em cada etapa da transmissão Fig. 3.18: jitter

12 LISTA DE TABELAS Tabela 1.1: As seis categorias de códigos de status Tabela 1.2: Comandos MEGACO Tabela 1.3: comparação entre MGCP e MEGACO Tabela 3.1: Métodos de Enfileiramento Tabela 3.2: Classificação do atraso

13 LISTA DE ABREVIATURAS ATM BECN CQ CRTP DE DiffServ DNS DoS FECN FIFO FQ GK GW HTTP IETF IIS IMTC INATEL IP IPsec IPtel ISDN ISI ITU LAN Mbone MC MCU MGCP MMUSIC MP ms PBX PQ PVP QoS RAS RDSI RED RFC RR RSVP RTCP RTP SDES SDP SIP SMTP SP Asynchronous Transfer Mode Modo de transferência Assíncrono Backward Explicit Congestion Notification Custom Queueing Compressed Real-Time Transport Protocol Discard Eligible Differentiated Services Domain Name System Denial of Service Forward Explicit Congestion Notification First In First Out Fair queuing Gatekeeper Gateway HyperText Transfer Protocol Internet Engineering Task Force Internet Integrated Services International Multimedia Teleconferencing Consortium Instituto Nacional de Telecomunicações Internet Protocol IP Security IP Telephony Integrated Services Digital Network Information Sciences Institute International Telecommunications Union Local Área Network Multicast Backbone on the Internet Multipoint Controller Multipoint Control Unit Media Gateway Controller Protocol Multiparty Multimedia Session Control Multipoint Processor Milisegundos Private Branch Exchanges Priority Queueing Packet Video Protocol Quality of Service Register, Admission and Status Rede de Serviços Digitais Integrada Random Early Detection Request For Comment Receiver Reports Resource Reservation Protocol Real-Time Control Protocol Real-Time Transport Source Descriptions Session Description Protocol Session Initiation Protocol Simple Mail Transfer Protocol Single Space 13

14 SPIT SR TCP UA UAC UAS UDP UFRJ URI URL USC VoFR VoIP VOMIT WAN WFQ WRED Spam Over IP Telephony Sender Reports Transmission Control Protocol User Agent User Agent Client User Agent Server User Datagram Protocol Protocolo de Datagrama do Usuário Universidade Federal do Rio de Janeiro Universal Resource Identifier Universal Resource Location University of Southern Califórnia Voice over Frame Relay Voice over IP Voz Sobre IP Voice Over Misconfigured Internet Telephones Wide Área Network Weighted Fair Queueing Weighted Random Early Detection 14

15 REDES DE TRANSMISSÃO DE VOZ SOBRE IP A Telefonia sobre IP (IPtel IP Telephony) é também designada como Voz sobre IP (VoIP Voice over IP) ou ainda Telefonia sobre Internet (Internet Telephony). A Telefonia sobre IP é definida como a comunicação multimídia entre dois ou mais participantes, em outras palavras, significa dizer que é uma ligação telefônica realizada através da rede IP. Porém o uso comum do termo telefonia IP não deve ser entendido somente como transporte de voz, mas também como transporte de outros tipos de meios como vídeo e dados. [siptel, p. 23] HISTÓRIA DO SURGIMENTO DAS REDES VOIP 1970 Dany Cohen começa os esforços para transportar áudio em redes de pacotes. Este relata uma experiência de transmissão de voz em pacotes e em tempo real entre o USC/ISI (University of Southern California/Information Sciences Institute) e o MIT s Lincoln Lab Surge o primeiro protocolo de internet para transportar voz em pacotes especificado formalmente por Dany Conhen [RFC 741, 1977] 1981 R. Cole propõe o Packet Video Protocol (PVP), um protocolo para o transporte de vídeo em pacotes A Internet Engineering Task Force (IETF) realiza a primeira audiocast através da Multicast Backbone on the Internet (MBone), a partir de San Diego. (RTP) Henning Schulzrinne começa a desenvolver o Real-Time Transport Protocol 15

16 após a primeira difusão de áudio, é feita pelo IETF, a partir de Boston através da Mbone a primeira difusão de áudio e vídeo simultaneamente, utilizando as aplicações vat e DVC respectivamente O RTP foi publicado como IETF Proposed Standard Steve McCanne e Van Jacobson desenvolveram a vic, uma aplicação que utiliza o codificador normalizado H Surgiu outra aplicação, o CU-SeeMe, que foi dos primeiros protótipos de videoconferência disponíveis na Internet. Inicialmente para MacOs e depois para Windows, este protótipo utilizava um processo responsável pela distribuição de sinais pelos vários intervenientes da conferência É publicada pela International Telecommunications Union (ITU) a primeira versão da recomendação H.323 [H.323, 1996] É prestado pela Delta Three o primeiro serviço comercial de Telefonia sobre IP, seguindo-se a Net2phone, ibasis e Telematrix A Microsoft lança o seu primeiro sistema de conferência sobre redes de pacotes. O Microsoft NetMeeting v O protocolo SIP foi aceite como norma, pelo IETF como um protocolo de sinalização para a criação, modificação e finalização de sessões com um ou mais participantes. A partir de então começou a ocorrer várias conferências empresariais [siptel, p. 21 a 23] 16

17 LIGAÇÃO TELEFÔNICA ATRAVÉS DE REDES IP Para que ocorra a comunicação multimídia entre dois ou mais participantes será necessário haver sinalização entre eles, de modo que o chamador avise o chamado sobre sua intenção. Esta sinalização tem como função a criação, controle e a finalização de chamadas. Este novo serviço permite a troca de pacotes entre dois ou mais participantes através da rede, utilizando protocolos da Internet e o intercâmbio da informação necessária para controlar essa troca. No chamador a voz é capturada por um microfone e o vídeo é obtido por uma câmara de vídeo sendo estes sinais geralmente digitalizados. Em seguida são codificados e encapsulados em pacotes que são enviados através da rede com a utilização de protocolos de Internet. Do outro lado, esses pacotes são desencapsulados e decodificados, o sinal digital é convertido em sinal analógico e reproduzido em alto-falantes enquanto o vídeo é enviado para a tela. VANTAGENS DA TRANSMISSÃO DE VOZ SOBRE IP O que realmente incentiva e impulsiona o desenvolvimento deste tipo de tecnologia são os benefícios que ela traz tanto para as corporações como para um usuário final. A idéia geral da utilidade das transmissões de voz sobre IP para as corporações será para integrar as tecnologias de rede em uma só infra-estrutura, ou seja, as corporações querem integrar a rede de dados com a rede de voz e vídeo. Essa integração entre estas redes pode trazer vários benefícios, entre eles estão: - Redução de custos: com a transferência das ligações telefônicas normais para as ligações telefônicas VoIP, reduz-se em cerca de 90% os custos com contas telefônicas. - Oferta de serviços: Várias pessoas se preocupam se com a convergência para ligações VoIP, obterão serviços como, por exemplo, secretária eletrônica. A resposta é SIM e além destes serviços normais, inúmeros outros já são oferecidos pelas ligações VoIP. 17

18 - Centralização da gestão destas infra-estruturas: com a integração de todas essas redes em uma única rede, fica mais fácil para o responsável pela infra-estrutura prover uma melhor qualidade de serviço, gerir a rede, administrar a rede e etc. A rede agora não ficará mais espalhada por vários fios e equipamentos, sua integração permitirá sua centralização, o que traz redução do uso de equipamentos e etc. - Arquitetura aberta: sua arquitetura é aberta e normalizada. Sua arquitetura possibilita a criação de novos serviços. - Privacidade: permite a autenticação de quem faz a chamada, através de uma palavrachave e certificados criptográficos. ARQUITETURA DAS REDES VOIP O que difere as redes VoIP das redes telefônicas tradicionais é a arquitetura de comutação. As redes telefônicas tradicionais são redes de comutação de circuitos enquanto a rede VoIP é uma rede de comutação de pacotes. Fig. 1.1: Arquitetura de uma rede VoIP [Inatel] Como visto na figura acima a rede VoIP é composta por vários dispositivos: 18

19 - Terminais: permitem executar os serviços como, por exemplo fazer e receber chamadas. Os terminais são dispositivos inteligentes, pois possuem total controle sobre o estado da chamada, ao contrário dos telefones tradicionais que apenas reagem a comandos de uma central controladora, refletindo uma arquitetura mestre-escravo. comunicação. - Gateways: permitem interligar duas redes que não usem a mesma tecnologia de - Servidores: funcionam ao nível da aplicação, controlando o encaminhamento das mensagens de sinalização. São também responsáveis pelos serviços de tarifação e controle de admissão. [siptel, p. 27] SERVIÇOS DA REDE VOIP Para se obter os serviços de voz sobre ip são necessários pelo menos cinco componentes. Estes componentes constituem o núcleo do serviço das redes VoIP e são necessários para a sua implementação. - Transporte: é responsável pelo transporte de informações entre as entidades, é feito em tempo real através do protocolo RTP. Este componente resolve os problemas de congestionamento, perda de pacotes, minimização de jitter e atraso de pacotes além dos problemas relacionados ao próprio transporte. - Controle de Transporte: responsável pela administração e controle do transporte de informações. O controle é feito através do protocolo RTCP. - Sinalização: é responsável pelo estabelecimento, controle e finalização de chamadas. - Aplicações: Implementa as características da voz sobre ip como a sinalização. Provê recursos como chamada em espera, conferência e etc. 19

20 - Descoberta de recursos: descobre os servidores (gateways, terminais e servidores) presentes na rede. Para realizar esta operação utiliza-se por exemplo o protocolo DNS (Domain Name System). OBSTÁCULOS PARA CONSOLIDAÇÃO DA REDE VOIP Embora seja uma grande tecnologia, a VoIP ainda apresenta alguns problemas, que devem ser sanados para que ela se consolide de vez. Entre esses problemas estão: - Qualidade de Serviço: As redes IP atuais, atuam oferecendo um serviço do tipo melhor esforço o que reduz a qualidade de serviço. - Segurança: Embora os novos serviços já ofereçam um mínimo de nível de segurança, a VoIP tem um grande obstáculo, a fama da internet de ser insegura. - Custo elevado: Mesmo com uma incrível redução de custos sofrida pelo produtos VoIP, estes ainda não conseguem apresentar um custo compatível com os oferecidos pelos produtos de telefonia tradicionais. - Confiabilidade: Ainda falta confiança no sentido de se estar seguro quanto a disponibilidade do serviço VoIP, quando se precisar dele como, por exemplo, para ligações de emergência. PROTOCOLOS DE SINALIZAÇÃO Os protocolos de sinalização tornam-se importantes para as transmissões de voz sobre ip, pois são os componentes da rede necessários para a troca de informações de controle e gerenciamento dos serviços de rede. Estes componentes podem fazer parte de dois grupos: 20

21 Protocolos mestre/escravo como, por exemplo, o MGCP e o Megaco e os Protocolos peerto-peer como, por exemplo, o H.323 e o SIP. Os protocolos mestre/escravo são usados quando os componentes inteligentes controlam os componentes sem inteligência como, por exemplo, a sinalização entre um SoftSwitch e um Media Gateway. Já os protocolos peer-to-peer são utilizados em interações entre elementos inteligentes como, por exemplo, a sinalização entre um SoftSwitch e telefones IP. [Voip_revolução_Telefonia.pdf] Fig. 1.2: Arquitetura Protocolar. [siptel] H.323 Introdução Histórica Os primeiros passos para o surgimento do H.323 foram dados pelo setor de Telecomunicações do ITU (International Telecommunication Union), o ITU-T, porém este 21

22 protocolo somente se deslanchou pelo mercado a partir da criação do fórum Voice over IP (VoIP), quem mais tarde viria a fazer parte do IMTC (International Multimedia Teleconferencing Consortium), cuja função seria, estabelecer padrões para os produtos VoIP. O H.323 teve seu trabalho iniciado em maio de 1995 com o seguinte título sistemas e equipamentos de telefone visual para redes locais que fornecem uma qualidade de serviço não garantida, e somente teve sua primeira versão aprovada em 1996, tornando-se H.323v1, que apesar de todas as forças empregadas, não foi bem vinda, devido ao seu baixo desempenho e problemas de compatibilidade entre os diversos fabricantes. Porém os esforços não pararam por ai, em janeiro de 1998 a segunda versão da recomendação H.323 foi aprovada, com seu título alterado para sistemas de comunicação multimídia com base em pacotes e acrescida de três anexos: mensagens H.245 usadas pelos pontos finais H.323; procedimentos para codecs de vídeo em camadas; H.323 sobre ATM. Com isso a segunda versão melhorou o tempo de estabelecimento da chamada e eliminou a necessidade de extensões proprietárias e novos protocolos. Contudo, queria-se chegar além, por isso em setembro de 1999 a terceira versão foi aprovada, contendo três novos anexos: comunicação entre domínios administrativos diversos com o H.225; um novo mecanismo de sinalização de chamadas com base no protocolo UDP; a especificação de um subconjunto do H.323 possível de ser implementado em dispositivos de pequeno porte. A evolução não parou por ai, pois em novembro de 2000 a quarta versão foi aprovada, trazendo melhorias em várias áreas importantes: confiabilidade, escalabilidade e flexibilidade. Sendo adicionadas novas características nas MCU (Gateways e Multipoint Control Unit), isso para deixar a recomendação conforme as exigências do mercado crescente da época. Finalmente chegamos a versão atual da recomendação H.323, a quinta versão, H.323v5, aprovada em julho de Esta versão se destaca pelo seu ar de estabilidade, pelo fato de conter somente adições modestas, alguns campos e somente um novo tipo de mensagem. No entanto o H.323 ainda não está totalmente concluído, sabendo-se que estudos para a aprovação da sexta versão estão acontecendo. Componentes da Recomendação H.323 Em um sistema H.323 são definidos alguns componentes conforme a recomendação H.323: Gatekeeper, MP (Multipoint Processor), Terminal H.323, MC (Multipoint Controller), MCU (Multipoint Control Unit) e Gateway. Esses componentes possuem características 22

23 distintas, e podem pertencer a uma única rede ou várias redes independentemente de conter uma ou várias infra-estruturas. Gatekeeper: é considerado o componente mais complexo da estrutura da recomendação H.323. Foi introduzido na primeira versão, H.323v1, apesar de na época poucos entenderem sua utilidade. Contudo na segunda versão, a recomendação H.323 esclareceu o papel do gatekeeper, e hoje o entendemos como sendo um elemento opcional da(s) rede(s), com funções como: tradução de endereços que é usado para se encontrar um alias; controle de chamadas o qual verifica a disponibilidade de recursos da rede; controle de admissão tanto à rede como a terminais, Gateways e MCU, cuja função é verificar o direito de acessar recursos; controle de registro para poder contactar alguém que está conectado ao sistema; reserva de recursos como largura de banda; localização de gateways. Enfim resumese gatekeeper como sendo um servidor que provê serviços multimídia para as entidades da rede e ainda gerencia toda a conferência. MCU (Multipoint Control Unit Unidade de Controle Multiponto): entidade, dispositivo que permite que vários terminais e/ou gateways participem de uma conferência Multiponto. Esta conferência pode ser iniciada apenas com dois terminais (ponto-a-ponto) e logo após poderá tornar-se uma conferência multiponto, com a entrada de mais terminais. A MCU é composta de duas partes, o MC (multipoint Controller) que é obrigatório, e o MP (Multipoint Processor) que é opcional. MC (Multipoint Controller Controladora Multiponto): geralmente é um software que controla o uso de recursos nas conferências multiponto, fazendo negociação com todos os terminais para obter uma comunicação igualitária. Também pode controlar outros recursos como por exemplo saber de quem é uma emissão de vídeo multicast. MP (Multipoint Processor Processador Multiponto): é uma entidade, geralmente um hardware, fornecida para processar o fluxo de áudio, vídeo e/ou dados em conferências multiponto. O MP ainda pode prover o processamento, mistura ou comutação de fluxos de mídia sob o controle do MC (multipoint controller). Terminal H.323: é um endpoint (ponto final), terminal, de uma rede. Provê uma interface que permite ao usuário realizar a comunicação bidirecional em tempo real (transferência de áudio, vídeo e/ou dados) com outro terminal H.323, gateway ou MCU. Um terminal H.323 pode ser um hardware (telefone IP), ou um computador multimídia 23

24 (microfone, caixas de som e câmera) que esteja utilizando um softphone (software que simula um telefone IP). Gateway: elemento da rede que realiza conversão (tradução de protocolo) entre terminais distintos, permitindo a interoperabilidade entre sistemas H.323 e outros sistemas em redes distintas. Também realiza serviços como compressão e empacotamento. Basicamente transforma a voz do usuário em pacotes de dados e vise-versa. Fig. 1.3: Componentes do padrão H.323 [Inatel] Recomendação H.323 para a Arquitetura Protocolar do H.323 O departamento de telecomunicações do ITU, o ITU-T, define que o padrão H.323 é um conjunto de protocolos necessários pra que haja sinalização e controle de comunicações entre terminais H.323. Portanto fazem parte dessa recomendação os seguintes protocolos: H (Q.931 procedimento de sinalização de comunicação entre os terminais das redes ISDN (RSDI)) que é o protocolo de sinalização de chamadas e encapsulamento de fluxo de dados multimídia para sistemas de comunicação baseada em pacotes. Define o método para o estabelecimento de chamadas H.323. A terminologia H (Q.931) é usada devido à 24

25 eficiência que o padrão Q.931 tem em estabelecer chamadas e o desejo do padrão H.225 se tornar compatível com essas redes. As principais funções do padrão H são: Sinalização de chamadas: Sob o canal de sinalização de chamadas (redes TCP/IP) trafegam várias mensagens sob o formato da recomendação Q.931, estas tem como objetivo sinalizar (iniciar e terminar) chamadas e trafegam entre os equipamentos (terminais H.323 e GK, ou entre GKs) que fazem parte da comunicação. Se a rede não possuir um gatekeeper estas mensagens são passadas ponto-a-ponto usando o endereçamento de sinalização da chamada, já nas redes que possuem o gatekeeper, as mensagens são trocadas entre o terminal chamador e o gatekeeper, utilizando mensagens de endereçamento RAS. Controle de conferência e equipamentos na rede: Esta fase é realizada após a sinalização da chamada e são utlizadas mensagens do tipo RAS (Register, Admission and Status) responsáveis pelo registro, admissão e status dos equipamentos da rede, estas mensagens definem o controle da rede e tem suporte aos pacotes UDP/IP. Comunicação entre Gatekeepers: São mensagens utlizadas na comunicação entre GKs (gatekeepers), para estabelecer o processo de sinalização e controle entre zonas distintas. Transporte de mídia: Para este evento utiliza-se os protocolos RTP (Real-Time Transport Protocol Protocolo de Transporte em Tempo Real) e o RTCP (Real-Time Control Protocol Protocolo de Controle em Tempo-Real), para o transporte de voz. H.245 (Control Protocol for Multimedia Communication Protocolo de Controle para Comunicações Multimídia) é o protocolo que fornece os padrões para o controle do transporte da voz entre as chamadas entre terminais. Estas mensagens tem suporte a TCP/IP e são enviadas entre Gateways e MCUs, de chamadas ponto-a-ponto ou ponto-multiponto. Este protocolo é utilizado depois do estabelecimento da chamada. O H.245 tem a capacidade de se adaptar às mudanças que ocorrem na rede, como por exemplo: alterações na disponibilidade da rede e/ou capacidades dos elementos H.323, isso deve-se a negociação dinâmica que ocorre entre terminais, que negociam vários aspectos da comunicação como por exemplo: formato de imagens e áudio, codecs e taxa de transmissão. O controle é feito através do canal lógico 0 (zero) que fica sempre aberto. No estabelecimento de uma sessão básica o H.323 utiliza três protocolos de controle, o RAS, o H.225.0/Q931 e o H

26 Fig. 1.4: Troca de mensagens entre entidades H.323. [siptel] H.235 (Security and Encryption for H-Series (H.323 and other H.245-based) Multimedia Terminals Segurança e criptografia para terminais multimídia da série H). É uma recomendação que fornece os padrões para autenticação e segurança entre comunicações ponto-a-ponto e multiponto. Esta recomendação é necessária para o estabelecimento de serviços de segurança no padrão H.323, como por exemplo: serviços de privacidade, autenticação, não repudiação e integridade. Para que isto aconteça o H.235 implementa técnicas de criptografia. H.450.X (Generic Funtional Protocol for the Support of Supplementary Services Protocolo de Funcionamento Genérico para o Suporte de Serviços Suplementares). Este protocolo fornece os padrões de sinalização para os serviços suplementares (comuns aos sistemas telefônicos atuais) para terminais, como por exemplo: atendimento simultâneo, identificação de chamadas e etc. Cada suplemento fornecido pelo protocolo H.450 é identificado através de um número inserido ao final da identificação do próprio protocolo H.450, como por exemplo: H define o serviço adicional de transferência de chamada (call transfer). 26

27 Fig. 1.5: Arquitetura Protocolar do H.323 [siptel] Fig. 1.6: Padrão H.323 [Inatel] Vantagens em se utilizar H.323 São várias as vantagens que podemos descrever sobre a utilização do padrão H.323 para aplicações multimídia, entre as quais citaremos: Rede Independente: O protocolo H.323 não requer mudanças na estrutura da rede, ou seja, pode ser adaptado na própria rede existente, isso se deve ao fato do protocolo H.323 ter sido projetado para ser usado em redes baseadas em pacotes, e hoje em dia a maioria das redes ter este aspecto. 27

28 Interoperabilidade de equipamentos e aplicações: O H.323 permite que haja comunicação (interoperabilidade) entre equipamentos e aplicações de diferentes fornecedores. operacional. Independência de plataforma: O H.323 pode operar sob qualquer hardware ou sistema Utilização de padrões de mídia: O H.323 faz uso de codecs de áudio e vídeo comuns, isso devido a negociação dos codificadores em uma chamada, para que os integrantes utilizem os mesmos codecs. Flexibilidade nas aplicações clientes: É a capacidade que o H.323 tem de comunicar um cliente que apresenta apenas suporte a áudio, com outro cliente que tenha suporte a áudio, vídeo e/ou dados. Interoperabilidade entre redes: É a capacidade que o cliente, que se encontra em uma rede, por exemplo, baseada em pacotes (redes IP) tem de se comunicar com outro cliente que se encontra em uma rede por exemplo ISDN. Isso ocorre através da utilização de um gateway. Suporte a gerenciamento de largura de banda: O H.323 permite o gerenciamento do consumo de largura de banda e também provê a contabilidade de uso dos recursos da rede, através da utilização do gatekeeper. Permite conferências multiponto: suporta além de conferências ponto-a-ponto, as multiponto, com três participantes ou mais. Suporte a multicast: Permite multicast em conferências multiponto, enviando um pacote a todo o subconjunto participante da conferência. Chamada H.323 Ilustraremos aqui uma chamada H.323 entre dois usuários conectados a dois terminais IP distintos, desconsiderando assim aspectos como segurança e tarifação. 28

29 Para se estabelecer uma chamada H.323 fim a fim requer-se duas conexões TCP entre os dois terminais participantes, uma conexão que servirá para se estabelecer a chamada e outra que tem como objetivo o controle da chamada e a troca de informações sobre capacidades. O primeiro passo significa ocorrer a primeira conexão TCP, ou seja, significa dar inicio a chamada. Esta primeira conexão é realizada da seguinte forma: - Primeiro o terminal chamador, estabelece uma conexão TCP com o terminal chamado através de uma porta conhecida. Nesta tentativa, a conexão transporta as mensagens de estabelecimento de chamada definidas no H Esta conexão é conhecida como canal de sinalização de chamadas. - Após estabelecer a chamada, o terminal chamado espera por outra conexão TCP em uma porta dinâmica; o terminal chamado comunica o número dessa porta na mensagem de aceitação de chamada. - Somente agora o terminal chamador então estabelece a segunda conexão TCP com o terminal chamado através da porta dinâmica. Esta segunda conexão transporta as mensagens de controle de chamada definidas no H Depois de estabelecida a segunda conexão, a primeira conexão deixa de ser necessária e pode ser finaliza por qualquer um dos participantes. [Telefonia IP] Mensagens de Chamadas H.323 As mensagens H.323 são enviadas entre o terminal chamador e o terminal chamado à medida em que a conexão entre ambos ocorre. PRIMEIRA FASE: INICIALIZANDO A CHAMADA O H.323 usa um subconjunto do protocolo Q.931, utilizado em ISDN (Integrated Services Digital Network Rede Digital de Serviços Integrados), de mensagens de sinalização para controle de chamada na interface usuário-rede. As seguintes mensagens fazem parte do núcleo do H.323 e devem ser suportadas por todos os terminais: Setup, Alerting, Connect, Release Complete, Status Facility. [Telefonia IP] 29

30 Fig. 1.7: Fluxo básico da conexão H.323 [UFRJ] Na figura César, tendo aberto a sessão no terminal A, deseja ligar para Bill (IP ). Primeiramente o terminal A envia ao terminal B uma mensagem Setup na porta conhecida do canal de sinalização de chamadas (porta 1720, como é definido pelo H.225.0, Apêndice D) usando uma conexão TCP. Após o recebimento da mensagem Setup por Bill, este envia a César as mensagens de Release Complete, Alerting, Connect ou Call Proceeding. Uma delas deve ser recebida pelo terminal de César antes que o temporizador de Setup expire (em geral, após quatro segundos). Após Alerting ter sido enviada, o usuário tem até três minutos para aceitar ou recusar a chamada. [Telefonia IP] SEGUNDA FASE: ESTABELECENDO O CANAL DE CONTROLE O controle da chamada e as mensagens de troca de capacidades são enviados na segunda conexão TCP. As mensagens são definidas no H.245. O terminal chamador abre esse canal de controle H.245 imediatamente após receber uma mensagem Alerting, Call Proceeding ou Connect, não importando qual delas especifica em primeiro lugar o endereço de transporte H.245 a ser usado. Esta segunda conexão que foi estabelecida deverá ser mantida ao longo de toda a chamada. 30

31 Nesta fase determina-se os papéis de quem será mestre e quem será escravo, isto é necessário quando a mesma função ou ação pode ser executada por dois terminais durante uma conversação e é necessário escolher apenas um (p. ex.: escolha do MC ativo, abertura de canais bidirecionais). No H.235, o mestre é responsável por distribuir as chaves de criptografia dos canais de mídia para os demais terminais. A determinação de quem será mestre é feita pela troca de mensagens masterslavedetermination que contém um valor terminaltype refletindo as capacidades do terminal e um número aleatório. Fig. 1.8: Negociação de Capacidades H.245. [UFRJ] TERCEIRA FASE: INÍCIO DA CHAMADA Agora o terminal A e o terminal B precisam abrir canais de mídia para voz e possivelmente para vídeo e dados. Para abrir um canal de voz até B, A envia uma mensagem H.245 OpenLogicalChannel que contém o número que será dado ao canal lógico, além de outros parâmetros. B envia uma mensagem OpenLogicalChannelAck referente a esse canal lógico tão logo esteja pronto para receber dados de A. Essa mensagem contém o número da porta UDP para qual A deve enviar os dados RTP e a porta UDP para a qual A deve enviar os dados 31

32 RTCP. Enquanto isso, B também pode ter aberto um canal lógico com A seguindo o mesmo procedimento. [Telefonia IP] Fig.1.9: Abrindo canais lógicos. [UFRJ] QUARTA FASE: DIÁLOGO Agora César e Bill podem conversar e ver um ao outro caso eles também tenham aberto canais lógicos para vídeo. Os dados da mídia são enviados em pacotes RTP. Os pacotes RTCP SR enviados por A são usados para permitir que B sincronize múltiplos fluxos RTP e também podem ser usados por B para estimar a taxa esperada de dados RTP e para medir a distância ao transmissor. Os pacotes RTCP RR enviados por B permitem que A meça a qualidade de serviço da rede entre A e B: as mensagens RTCP contêm a fração de pacotes que foram perdidos desde o último RR, a perda cumulativa de pacotes, o jitter entre chegadas e o mais alto número de seqüência recebido. Os terminais H.323 devem responder ao aumento da perda de pacotes reduzindo a taxa de envio dos mesmos. Observe que o H.323 manda usar apenas um par de portas RTP/RTCP para cada sessão. Podem haver três sessões principais entre os terminais H.323: a sessão de áudio, a sessão de vídeo e a sessão de dados, mas nada no padrão impede que um terminal abra mais sessões. Para cada sessão deve haver apenas uma porta RTCP usada, isto é, se houver simultaneamente um fluxo RTP de A para B e de B para A, o transmissor RTCP e os RRs para ambos os fluxos vão usar a mesma porta UDP. [Telefonia IP] 32

33 Fig. 1.10: Conversação ativa H.323. [UFRJ] QUINTA FASE: FINALIZANDO UMA CHAMADA Caso seja César quem vai finalizar a chamada, o terminal A deve enviar uma mensagem H.245 CloseLogicalChannel para cada canal lógico que A abriu. B acusa o recebimento dessas chamadas com uma mensagem CloseLogicalChannelAck. Depois de todos os canais lógicos terem sido fechados, A envia uma mensagem H.245 endsessioncommand, espera até que tenha recebido a mesma mensagem de B e fecha o canal de controle H.245. Finalmente, A e B devem enviar uma mensagem H.225 ReleaseComplete através do canal de sinalização de chamadas se ele ainda estiver aberto; esse canal é então fechado, assim como a chamada. SIP Introdução SIP (Session Initiation Protocol Protocolo de Iniciação de Sessão), é um protocolo de sinalização/controle de chamadas em redes IP. É uma arquitetura que se originou em 33

34 meados dos anos 90 na Universidade de Columbia e depois foi normalizada pelo grupo de trabalho MMUSIC ( Multiparty Multimedia Session Control) do IETF (Internet Engineering Task Force). Foi definida inicialmente pela RFC (Request For Comment) 2543 em março de 1999, e logo após teve alguns aspectos melhorados que foram definidos na RFC 3261 em Características As principais características do protocolo SIP são escalabilidade, flexibilidade e facilidade de criação de serviços, o que o torna um protocolo de fácil integração junto às aplicações já existentes na internet, isso se deve as semelhanças com os protocolos HTTP (HyperText Transfer Protocol) e SMTP (Simple Mail Transfer Protocol). O SIP foi criado com a finalidade de ser um protocolo mais fácil do que os já existentes no mercado, exemplo H.323, esta facilidade esta presente na criação, modificação e finalização de sessões, que podem ocorrer entre um ou vários integrantes. SIP é um protocolo cliente-servidor, e tem um sistema final que interage com o usuário. Arquitetura do SIP A arquitetura do SIP é composta de vários componentes denominados entidades SIP, entre eles estão: User Agent SIP (UA SIP - Agente do Usuário SIP): São os terminais finais de comunicação (terminal SIP ou softphone). Este agente atua como um cliente/servidor, sendo a parte cliente conhecida como UAC User Agent Client, uma entidade lógica que realiza a inicialização da sessão através do envio de pedido(s) para o servidor. O servidor, também uma entidade lógica conhecida como UAS User Agent Server, realiza o envio de respostas aos pedidos recebidos do cliente, dessa forma o agente consegue ter controle sobre a sessão. 34

35 Servidor Proxy SIP: este servidor é subdividido em outros componentes, que são explicados abaixo: Proxy Server - Servidor Proxy: é um servidor intermediário, que pode atuar tanto como cliente quanto como servidor. Tem a função de estabelecer chamadas entre os integrantes da chamada, encaminhando os pedidos recebidos até o destino, sendo assim pode passar ou não por outros servidores proxy. Pode ser utilizado para contabilidade, pois armazena informações. Opera através das comunicações stateful (circuito) ou stateless (TCP). Redirect Server - Servidor de Redirecionamento: é um servidor intermediário, um UAS User Agent Server, cuja função é fornecer informações sobre o usuário destino, para isso, utiliza o DNS que resolve nomes. Registrer Registrador: entidade cuja finalidade é fornecer informações sobre as localizações que conhece. Estas informações estão gravadas na entidade, pois a mesma anteriormente já recebeu outra requisição igual. Fig. 1.11: Arquitetura Sip. [UFRJ] 35

36 Mensagens SIP Mensagens SIP são codificadas usando a sintaxe de mensagem http/1.1 (RFC 2068). O conjunto de caracteres é o ISO com codificação UTF-8 (RFC 2279). Há dois tipos de mensagens SIP: pedidos (requests) e repostas (responses). [Telefonia IP, p. 125] Os pedidos são feitos através dos clientes e as repostas são retornadas através do(s) servidor(es). A mensagem SIP é constituída da linha de ínicio, cabeçalhos, linha em branco e o corpo da mensagem. Versão do SIP SP Código de Status SP Frase-Motivo CRLF para resposta Método SP URL do pedido SP Versão do SIP CRLF para pedidos Linha de início aaa=bbb ccc=ddd eee=fff Cabeçalhos Linha em branco Corpo da mensagem (SDP limpo, SDP criptografado, ) Fig. 1.12: O formato de mensagem SIP [Telefonia IP, p. 124] A linha de início contém a versão do SIP, SP (single space espaço simples) que é um formato comum compartilhado entre as mensagens de pedidos e repostas, Código de Status, Frase-Motivo, CRLF utilizado para resposta. Os cabeçalhos transportam informações úteis as entidades SIP, para que estas possam gerar mensagens de pedidos ou respostas. A parte cabeçalho da mensagem SIP é dividida em três partes: cabeçalho de geral, cabeçalho de pedido e cabeçalho de entidade. A linha em branco é sempre utilizada logo após os cabeçalhos para indicar o fim dos mesmos. 36

37 O corpo da mensagem é opcional. Caso ele exista irá descrever a sessão através do protocolo SDP (Session Description Protocol Protocolo para descrição de sessão). O cabeçalho geral contém campos que são comuns para as mensagens de pedidos e respostas. Estes campos são: Call-ID: é o identificador da chamada, deve ser igual em todas as mensagens geradas durante uma chamada. Cseq: contém o número de seqüência que é incrementado a cada novo pedido. Este número permite identificar e ordenar as mensagens dentro das transações. From: Contém o endereço do usuário chamador. To: indica o endereço do destinatário. Via: indica a rota que a requisição deverá seguir, contém o tipo de transporte e o endereço de destino. Encryption: serve para identificar quando o corpo da mensagem e, possivelmente, alguns cabeçalhos de mensagem foram criptografados. [Telefonia IP, p. 126]. Content-Type: descreve o tipo [Telefonia IP, p. 126] de mídia do conteúdo do corpo da mensagem. p.126]. Content-lenght: significa o número de octetos do corpo da mensagem. [Telefonia IP, Mensagens de Pedidos (Requests) SIP As mensagens de pedido realizadas pelo protocolo SIP, partem do cliente para o servidor. Existem vários tipos de mensagens que ocorrem dessa forma e cada uma delas é transportada em uma parte da mensagem. As mensagens transportadas no cabeçalho geral são: 37

38 ACK: um pedido ACK é enviado pelo cliente para confirmar que ele recebeu uma resposta final do servidor, como 200 OK; [Telefonia IP, p. 126] BYE: um pedido BYE é enviado pelo agente de origem ou pelo agente de destino para interromper uma chamada; [Telefonia IP, p. 128] Cancel: um pedido Cancel pode ser enviado para interromper um pedido que foi enviado anteriormente enquanto o servidor ainda não tiver enviado uma resposta final; [Telefonia IP, p. 128] Invite: o pedido Invite é usado para iniciar uma chamada; [Telefonia IP, p. 128] Options: um cliente envia um pedido Option ao servidor para saber suas capacidades. O servidor envia de volta uma lista com os métodos que ele suporta. Em alguns casos, ele também pode responder com o conjunto de capacidades do usuário mencionado na URL (Uniform Resource Locator Localizador Uniforme de Recursos) e como ele teria respondido a um convite; [Telefonia IP, p. 128] Register: clientes podem registrar sua localização atual (um ou mais endereços) com o pedido Register. Um servidor SIP capaz de aceitar uma mensagem Register é chamado de registrar. [Telefonia IP, p. 128] Além do campos do cabeçalho geral, os pedidos podem transportar campos no cabeçalho de pedido: Accept: indica quais os tipos de mídia são aceitáveis na resposta. A sintaxe é especificada no RFC 1288; [Telefonia IP, p. 128] Accept-Language: indica as línguas preferidas do originador da chamada. A sintaxe é especificada no RFC 1288; [Telefonia IP, p. 129] Expires: para uma mensagem Register, indica por quanto tempo o registro será válido. Para uma mensagem Invite, isso pode ser usado para limitar a duração de buscas; [Telefonia IP, p. 129] 38

39 Priority: os valores são os do RFC 2076, mais emergency ; [Telefonia IP, p. 129] Record-Route: alguns proxies podem adicionar / atualizar esse campo de cabeçalho, se eles quiserem estar no caminho de todas as mensagens de sinalização. [Telefonia IP, p. 129] Subject: é um texto livre que deveria fornecer alguma informação sobre a natureza da chamada. [Telefonia IP, p. 129] Linha de início INVITE SP sip: john@domain.com SP SIP/2.0 CRLF Via: SIP/2.0/UDP Call-ID; @warchester.bell-telephone.com From: <sip:a.g.bell@bell-telephone.com> TO: T.A. Watson <sip:watson@bell-telephone.com> Call-ID: @warchester.bell-telephone.com Cseq: 1 INVITE Cabeçalho geral Cabeçalho de pedido Subject: Mr. Watson, come here. Content-Type: application/sdp Content-Length: 885 <CR LF> Cabeçalho da entidade Linha em branco v=0 o=bell IN IP c=in IP m=audio 3456 RTP/AVP Fig. 1.13: O formato da mensagem de pedido SIP [Telefonia IP, p.128] Dados SDP 39

40 Mensagens de Respostas (Responses) SIP As respostas SIP são geradas no(s) servidor(es) para atender a uma mensagem pedido que recebeu anteriormente. As respostas SIP seguem um padrão de códigos de status: : Informação Provisória; : Sucesso; : Redirecionamento; : Erro no cliente; : Erro no servidor; : Falha global; 1xx Informativo Pedido recebido, continuando a processar o pedido 100 Tentando 180 Chamando 181 A chamada está sendo retransmitida 182 Colocado na fila 2xx Sucesso A ação foi recebida, entendida e aceita com sucesso 200 OK 3xx Redirecionamento Uma ação adicional deve ser tomada para completar o pedido 300 Múltiplas escolhas 301 Movido permanentemente 302 Movido temporariamente 380 Serviço alternativo 4xx Erro do cliente O pedido contém sintaxe inválida ou não pode ser efetuado neste servidor 400 Pedido inválido 401 Não autorizado 402 Necessário pagamento 403 Proibido 404 Não encontrado 405 Método não permitido 406 Não aceitável 407 Necessária autenticação no proxy 408 Tempo para o pedido esgotado 409 Conflito 410 Não mais presente 411 Necessário fornecer comprimento 413 Corpo da mensagem de pedido muito grande 40

41 414 URL do pedido muito grande 415 Tipo de mídia não suportado 420 Extensão inválida 480 Temporariamente não disponível 481 Transação ou leg de chamada não existe 482 Laço (loop) detectado 483 Excesso de segmentos (hops) 484 Endereço incompleto 485 Ambíguo 5xx Erro de servidor 500 Erro interno no servidor 501 Não implementado 502 Gateway inválido 503 Serviço não disponível 504 Tempo esgotado no gateway 505 Versão SIP não suportada 6xx Falha global 600 Ocupados em todos os lugares 603 Declínio 604 Não existe em lugar nenhum 606 Não aceitável Tabela 1.1: As seis categorias de códigos de status. [Telefonia IP, p. 130] 41

42 SIP/ Moved temporarily Linha de status From: sip: To: sip: tag= Call-ID: Location: Expires: Wed, 29 jul :00:00 GMT Cseq: 1 INVITE cabeçalhos Linha em branco Dados da resposta (SDP limpo, SDP criptografado, text/plain ou text/html) Fig. 1.14: O formato da resposta SIP [Telefonia IP, p. 131] Chamadas SIP As chamadas SIP são compostas de várias etapas: início da chamada, finalização da chamada, rejeição da chamada entre outros. INICIANDO UMA CHAMADA SIP Para que se inicie uma chamada SIP, o iniciador da chamada (cliente SIP) deverá conhecer o endereço SIP da pessoa a ser chamada (servidor SIP). São vários os tipos de endereços SIP. O cliente/servidor SIP é identificado através do URI (Universal Resource Identifier Identificador Universal de Recursos) definido na RFC 3261 de O URI identifica o utilizador através das seguintes formas: sip:utilizador@dominio, sip:utilizador@host, sip:utilizador@ip-address ou sip:numerotelefone@gateway. 42

43 Sabendo-se o URI da pessoa a ser chamada, o cliente deverá então abrir uma conexão entre ele próprio e o destino, este estabelecimento de chamada se da inicialmente através do envio de um INVITE para o destinatário, neste ponto do processo após o envio do INVITE, o terminal chamado recebe o invite, ambos trocam informações (mídia, endereço de destino, porta e etc) sobre como a sessão será realizada, o terminal chamado aceita a conexão, o terminal chamador confirma o aceite e finalmente ambos estabelecem a conexão. Originador da chamada Pessoa a ser chamada Envio do INVITE Resposta OK e informações sobre mídia, porta e etc Mensagem ACK Fig. 1.15: Chamada ponto-a-ponto SIP [Telefonia IP, p. 119] Troca de informações FINALIZANDO UMA CHAMADA SIP A finalização de uma chamada SIP pode ser realizada por qualquer umas das partes envolvidas através do envio de um pedido BYE. Caso a conexão seja ponto-a-ponto, apenas o que irá mudar em relação a finalização da chamada ser realizada pelo cliente ou pelo servidor será a ordem dos campos From e To. 43

44 A Troca de informações B BYE sip: a@ SIP/2.0 v: SIP/2.0/UDP :3456 i: a2e3a@ From: sip:b@ To: sip: a@ Cseq 2 BYE SIP/ OK Via: SIP/2.0/UDP :3456 Call-ID: a2e3a@ From: sip: b@ To: sip: a@ Cseq 2 BYE Fig. 1.16: Finalização de uma chamada SIP [Telefonia IP, p. 122] ALTERAÇÃO DE CHAMADA SIP A alteração da chamada SIP consiste na troca de parâmetros como, por exemplo, mídia, endereços e portas, entre as partes, chamador e chamado durante a realização da mesma sem que para isso a sessão deva ser finalizada. A B INVITE 200 OK ACK Troca de informações Fig. 1.17: Alteração de chamada SIP [Telefonia IP, 122] 44

45 No caso da figura acima as alterações foram aceitas com sucesso pelo utilizador B, isso pode ser visto através do envio por parte de B da mensagem 200 OK após o recebimento do invite enviado por A. Porém caso B rejeita-se a troca de parâmetros proposta por A, ambos continuariam a utilizar os parâmetros antigos até o fim da chamada ou até uma nova tentativa de troca de parâmetros que viesse a ter sucesso. É importante saber que ambas as partes envolvidas na chamada, A e B, podem propor a qualquer momento da chamada uma troca de parâmetros. REJEIÇÃO DE CHAMADA SIP A rejeição de chamada é muito funcional pois, por vários motivos a pessoa chamada pode não querer atender a ligação como também pode não poder atender no momento. A B INVITE SIP/ Busy Here Via: SIP/2.0/UDP :3456 Call-ID: a2e3a@ From: sip: a@ To: sip: john@ Cseq 1 INVITE ACK sip: B@ SIP/2.0 Via: SIP/2.0/UDP :3456 Call-ID: a2e3a@ From: sip: a@ To: sip: b@ Cseq 2 ACK Fig. 1.18: Resposta busy here [Telefonia IP, p.123] COMPARAÇÃO ENTRE H.323 E SIP A primeira coisa que impressiona ao se estudar o protocolo SIP é sua velocidade e simplicidade em relação ao H.323, pois o SIP consegue fazer em uma transação o que o H.323 faz em várias. Outra vantagem impressionante é que o SIP funciona muito bem em 45

46 backbones com capacidade para multicast, não apenas para os fluxos de mídia como também para as mensagens de sinalização. O SIP ainda toma vantagens no uso de URLs para identificação dos usuários pois ele mesmo especifica o protocolo na URL (Universal Resource Location), ao passo que o H.323 sempre considera que o protocolo de sinalização que está sendo usado seja ele mesmo. Nas inúmeras vantagens do protocolo SIP sobre o H.323 ainda podemos encontrar o campo de cabeçalho Priority que não existe no H.323. Mas não é somente o SIP que tem vantagens, também podemos encontrar muitas vantagens ao se utilizar o protocolo H.323 como, por exemplo, o uso de canais lógicos pelo protocolo H.323. O H.323 faz uma distinção clara entre os tipos de mídia que podem ser enviados ou recebidos e as combinações que podem ser válidas por um lado (capacidades) e os tipos de mídia que estão ativos e, de fato, enviados para a rede (canais lógicos) por outro lado. O cliente H.323 também toma vantagem ao precisar abrir um soquete apenas quando ele recebe uma mensagem OpenLogicalChannel (se não estiver no modo FastStart). O H.323 sozinho ou em combinação com o H.332, possui recursos poderosos para controle de conferências. [Telefonia IP, p. 153 a 157] PROTOCOLO SDP SDP é um protocolo utilizado pelo SIP para descrever sessões. O SDP (Session Description Protocol Protocolo de Descrição de Sessão) está definido na RFC 2237 de 1998 e também é um produto do grupo de trabalho MMUSIC. [Telefonia IP, p. 131] Este protocolo define para um utilizador informações como tipos de áudio e vídeo que ele suporta, porta onde deverá receber os dados, nome da sessão e propósito, duração da sessão, informação de contato, largura de banda e etc., estas informações são transportadas juntamente com a mensagem SIP. A real finalidade do protocolo SDP é atuar como um negociador entre as partes envolvidas na chamada já que este carrega consigo todas as informações que são úteis para o estabelecimento da chamada. Visto que nem sempre as partes se entendem sobre, por exemplo, que tipo de áudio e vídeo irão utilizar, o SDP de ambas as partes ficam fornecendo 46

47 informações sobre os áudios e vídeos, entre outras informações, que suportam até que ambos entrem em um consenso. Fig. 1.19: Exemplo da utilização do SDP numa mensagem SIP. [siptel, p. 43] PROTOCOLOS ENTRE GATEWAYS DE MÍDIA E CONTROLADORES DE MÍDIA São protocolos que atuam como uma interface entre um controlador de gateway de mídia e um gateway de mídia. Controlador de gateway de mídia é um agente de chamada e o gateway de mídia, pode ser qualquer gateway VoIP. Citaremos agora os protocolos entre gateways de mídia e controladores de mídia mais atuais. MGCP MGCP (Media Gateway Controller Protocol Protocolo de Controle de Media Gateway), é um protocolo que está definido através da recomendação RFC 2705 do IETF, é 47

48 usado para controlar as conexões (chamadas) nos GW s presentes nos sistemas VoIP. O MGCP implementa uma interface de controle usando um conjunto de transações do tipo comando resposta que criam, controlam e auditam as conexões (chamadas) nos GW s. Estas mensagens usam como suporte os pacotes UDP da rede IP, e são trocadas entre os GC s e GW s para o estabelecimento, acompanhamento e finalização de chamadas. [Teleco] Fig. 1.20: Arquitetura MGCP geral. [Unisal] O gateway de telefonia é um elemento de rede que provê conversação entre o sinal de áudio transportado nos circuitos telefônicos e converte para pacotes de dados transportado na internet ou outras redes de pacotes. A RFC do MGCP suporta vários tipos de gateways de telefonia, entre eles podemos citar: - gateways de tronco: Fazem a interface entre a rede telefônica e a rede VoIP; - gateways residenciais: Fazem uma interface analógica tradicional (RJ11) com a rede de VoIP; - gateways de acesso: Fazem uma interface analógica (RJ11) ou interface digital do PBX corporativo para a rede IP; - gateways corporativos: fazem uma interface padrão digital com o PBX corporativo ou integrado como uma interface soft PBX para uma rede VoIP; - Servidor de Acesso a rede: Podem associar a um modem ou um circuito telefônico e prover acesso de dados para internet, prover com o mesmo gateway acesso combinado para os serviços das rede de voz e serviços de rede. 48

49 O MGCP pode-se dizer que é um protocolo mestre/escravo, pois os gateways ficam aguardando para executar comandos dos Call Agents. Em seu modelo de conexão, a contrução básica são os endpoints e as conexões. Os endpoints são as fontes e pontos finais de dados. Entre os endpoints usa-se o protocolo SDP para a descrição de mídias na negociação das mesmas. Fig. 1.21: Arquitetura do MGCP - Residential Gateways - Solução Clarent [UFRJ] Fig. 1.22: Arquitetura do MGCP - Trunking Gateways Solução MCI [UFRJ] O ambiente MGCP é composto basicamente de um Call Agent, e um conjunto de gateways, incluindo pelo menos um mídia gateway que realiza a conversão das mídias entre 49

50 os circuitos e os pacotes, e pelo menos um gateway de sinalização! Onde este é conectado com uma rede controlada por SS7. Comandos MGCP Fig. 1.23: Comandos MGCP. [Unisal] MEGACO O protocolo Megaco é uma evolução do MGCP, resultado de um esforço conjunto do IETF e do ITU-T (Grupo de Estudo 16). O texto da definição do protocolo e o mesmo para o Draft IETF e a recomendação H.248, e representa uma alternativa ao MGCP e outros protocolos similares. Este protocolo foi concebido para ser utilizado para controlar GW s monolíticos (1 único equipamento) ou distribuídos (vários equipamentos). Sua plataforma aplica-se a gateway (GW), controlador multiponto (MCU) e unidade interativa de resposta audível (IVR). Possui também interface de sinalização para diversos sistemas de telefonia, tanto fixa como móvel. [Teleco] 50

51 Comandos MEGACO Tabela 1.2: Comandos MEGACO. [Unisal] COMPARAÇÃO ENTRE MGCP E MEGACO 51

52 Tabela 1.3: comparação entre MGCP e MEGACO. [Unisal] PROTOCOLO RTP O RTP (Real-Time Transport Protocol Protocolo de Transporte em Tempo Real) [RFC 1889, 1996] foi projetado para permitir que os receptores compensem o jitter e a perda de seqüência dos pacotes introduzidos pelas redes IP. O RTP pode ser usado para qualquer fluxo de dados em tempo real, como voz e vídeo. O RTP define um modo de formatar pacote IP que carregam dados isócronos e inclui: - Informação sobre o tipo de dado transportado; - timestamps; - números de seqüência. [Telefonia IP, p. 10] O RTP atua entre as aplicações e os protocolos da camada de transporte. É um protocolo independente das camadas de rede e de transporte por isso, pode ser implementado sob qualquer protocolo. Com a implementação do RTP sobre o UDP, seu uso mais comum, as vantagens obtidas tornam-se maiores ainda pois, além da simplicidade do UDP mais dois serviços são disponibilizados: a multiplexação e a correção de erros. O RTP é implementado mais comumente sobre o UDP pois, ele não se preocupa com a entrega ou atraso de dados, QoS tão quanto reserva de recursos, espera-se que este serviço seja oferecido pelos protocolos que o encapsulam. [RTP_RTCP.pdf, p. 7] 52

53 FUNCIONALIDADES DO RTP O protocolo RTP possui inúmeras funcionalidades dentre elas estão: Seqüência: é o número que ordena os pacotes, usado para verificação de perdas e/ou reordenamento de pacotes; Sincronismo: o RTP provê informações sobre o tempo de cada pacote, isto é necessário para a reprodução da mídia com qualidade. Identificação de quadro: quadros fazem parte de pacotes, o RTP marca o início e o fim de cada pacote, necessário para identificação deste quadro. Identificação de origem: indica quem enviou o pacote. Criptografia: Alguns streams de RTP podem ser criptografados. pessoais. Liberdade no controle da sessão: permite aos participantes trocarem informações Qualidade de Serviço: o destinatário tem a possibilidade de fornecer informação sobre a qualidade da recepção. [VoIP, p. 19] PACOTE RTP O pacote RTP é constituído de um cabeçalho RTP fixo, uma lista de fontes de contribuição e um payload (conteúdo do pacote). [RTP_RTCP.pdf, p.8] 53

54 Fig. 2.1: Pacote RTP [< acesso em: 26/05/2005] V: Versão do RTP; P: padding, indica se o payload sofreu enchimento para fins de alinhamento. X: indica se há extensões após eventuais CSRCs do cabeçalho fixo. CC: informa quantos identificadores CSRC vêm após o cabeçalho fixo. M: O H informa que, para codificações de áudio que suportam supressão de silêncio, ele deve ser colocado em 1 no primeiro pacote de cada período de fala subseqüente a um período de silêncio. PT payload type: indica o tipo de payload. Sequence Number: Número de seqüência, começa com um número aleatório e é incrementado a cada pacote RTP. Time Stamp: indica a freqüência do clock para o tipo de payload. Synchronization Source Identificator (SSRC): Identificador de fonte de sincronização, todos os pacotes RTP com um SSRC comum possuem uma mesma referência de tempo e de seqüenciamento. 54

55 Contributive Source Identificator (CSRC): Identificador de fonte contribuinte, quando um fluxo RTP é o resultado de uma combinação de vários fluxos contribuintes feita por um misturador (mixer) RTP, a lista com os SSRCs de cada um dos fluxos contribuintes é adicionada ao cabeçalho RTP do fluxo resultante como uma lista de CSRCs. O fluxo resultante tem o seu próprio SSRC. Data: dados. [Telefonia IP, p.12 e 13] SESSÃO RTP Uma sessão RTP é uma associação de participantes que se comunicam no RTP. Cada participante usa dois endereços de transporte para cada sessão: um para o fluxo RTP e um para as mensagens RTCP. Quando uma transmissão multicast é usada, todos os participantes usam o mesmo par de endereços de transporte multicast. Fluxos de dados na mesma sessão devem compartilhar um canal RTCP comum. [Telefonia IP, p. 12] Se em uma conferência estiver sendo transmitido áudio e vídeo, estes serão transmitidos em sessões RTP distintas. Nestas sessões os pacotes RTCP de um emissor terão o mesmo identificador, e as sessões RTP podem associar-se. O objetivo da divisão é permitir ao participante escolher as mídias que quer receber de acordo com seus recursos de rede e processamento local. [RTP_RTCP.pdf, p.12] Manter fluxos de mídias diferentes numa mesma sessão RTP traz uma série de problemas: - Se o tipo de payload for mudado durante a sessão, não haverá como saber qual dos valores antigos foi alterado; - O identificador SSRC é designado para descrever apenas um escopo de temporização e de número de seqüência; - RTCP sender e receiver reports podem indicar apenas uma fonte SSRC; - Um RTP mixer não saberia combinar mídias incompatíveis; - Não poderia haver usos e implementações específicas de cada meio. 55

56 Embora a divisão de sessões não seja recomendada, a sincronização de áudio e vídeo pode ser obtida através das informações de tempo carregadas nos pacotes RTCP. [RTP_RTCP.pdf, p.13] QUALIDADE DE SERVIÇO O conceito de QoS (Quality of Service Qualidade de serviço) sobre redes IP somente foi pensado a pouco, em um passado não tão distante o que apenas era oferecido era um serviço, o de melhor esforço (best effort), o que não garantia QoS. O que realmente levou a qualidade de serviço ao auge foram os novos serviços que puderam ser oferecidos sobre as redes IP, áudio e vídeo. Com a implantação desses novos serviços vários parâmetros começaram a ser abordados, entre eles os mais comuns que caracterizam a qualidade de serviço são: latência, largura de banda e perda de pacotes ou de seqüência. Vários institutos, pessoas e etc., tem se mobilizado para estudar melhores formas de prover qualidade de serviço. A primeira das propostas foi feita pelo grupo de trabalho Integrated Services do IETF, foi uma arquitetura de integração de serviços, chamada Internet Integrated Services (IIS) que propõe melhorar o desempenho da camada de rede, assegurando a reserva de recursos. A segunda proposta é feita pelo grupo Differentiated Services (DiffServ) do IETF, uma arquitetura de diferenciação de serviços na internet. A terceira proposta baseia-se na negociação de serviços de rede, para a utilização de múltiplos serviços de rede. A quarta é baseada na utilização de mecanismos adaptativos que tentam reduzir as perdas e os atrasos de pacotes, através do uso de mecanismos adaptativos utilizados ponto a ponto. A quinta baseia-se no envio de correções de erro, fornecendo mecanismos de redundância para ultrapassar a perda de pacotes em streams multimídia. [siptel, p. 28,29 e 30] MODELO BÁSICO DE QoS 56

57 QoS nos dias de hoje tem o grande objetivo de priorizar o tráfego interativo sensível a retardo, em detrimento ao tráfego referente à transferência de arquivos, que não é sensível a retardo. Fig. 3.1: Modelo para QoS [ Voip_Ramon.pdf, p.21] O que se pode observar na figura acima é que a qualidade de serviço deverá ser tratada independentemente em cada umas das partes que passam/repassam o pacote de dados incluindo sua origem e destino. CONGESTIONAMENTO Pensar em congestionamento é muito simples, basta lembrar-mos das horas que ficamos nos congestionamentos de trânsito, ou então nos inúmeros finais de ano que passamos tentando ligar para alguém e as redes de telefonia encontram-se congestionadas devido aos inúmeros telefonemas que ocorrem no mesmo instante. O mesmo ocorre nas redes IP, porém com um toque a mais de dificuldade, já que o que estamos tratando é algo relativamente novo. Para resolver o problema de congestionamento em redes ip vários artifícios foram estudados afim de se controlar e prevenir este tipo de problema. Estes artifícios são chamados de mecanismos de enfileiramento. Alguns desses mecanismos são: Fifo 57

58 First In First Out primeiro a entrar, primeiro a sair. Também chamado de primeiro a chegar, primeiro atendido (First Come, First Served FCFS). Simplesmente emite os pacotes na ordem em que foram recebidos. Um exemplo da utilização deste método são nas conexões seriais dos roteadores. Fig. 3.2: Operação da Fila FIFO [VoIP_Ramon.pdf, p. 22] Os roteadores apresentam uma programação defaul quando são utilizados pela primeira vez, e continuam assim até que alguém a mude. Esta programação default diz que a ordem de chegada dos pacotes é que determina a alocação de banda, e o que chega primeiro é logo atendido. A desvantagem de se usar FIFO é quando ocorre trafego de rajada, isso pode causar atrasos, portanto FIFO não serve para aplicações sensíveis a QoS. Fair Queueing FQ - Fair queuing enfileiramento justo. Neste algoritmo as mensagens são ordenadas em sessões, e, para cada sessão, é alocado um canal. A ordem na fila é realizada através do ultimo bit que atravessa o canal. Essa operação provê uma alocação mais justa da banda entre os fluxos de dados. [VoIP_Ramon.pdf, p.22] Fig. 3.3: Filas Fair Queueing [VoIP_Ramon, p. 22] 58

59 O algoritmo WFQ (Weighted Fair Queueing Enfileiramento Justo Balanceado) é uma implementação Cisco na qual é possível ponderar determinados tipos de fluxo. O algoritmo escalona o tráfego prioritário na frente da fila, reduzindo o tempo de resposta. Ao mesmo tempo, compartilha o restante da banda com os outros tipos de fluxo de uma forma justa. O WFQ é dinâmico e se adapta automaticamente às mudanças das 2Mbps. [VoIP_Ramon.pdf, p. 23] Fig. 3.4: Operação do Algoritmo WFQ [VoIP_Ramon.pdf, p.23] Por apresentar um desempenho superior à fila FIFO, a fila WFQ já vem préconfigurada nas interfaces seriais da maioria dos roteadores. [VoIP_Ramon.pdf, p. 23] Fig. 3.5: Filas WFQ [VoIP_Ramon.pdf, p.23] 59

60 Como pode ser verificado na figura, a classificação dos fluxos de dados pode ser realizada de diversas formas: por endereço fonte ou destino, por protocolo, pelo campo preedência IP, pelo par porta/socket, etc. A quantidade de filas é configurável e a ponderação pode ser estabelecida por preedência IP, ou em conjunto com outros protocolos de QoS como o RSVP, ou ainda em tráfego Frame Relay, como VoFR (Voice over Frame Relay) por exemplo, através dos parâmetros FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification) e DE (Discard Eligible). [VoIP_Ramon.pdf, p.23] Priority Queueing Numa fila com Enfileiramento Priority Queueing - PQ (enfileiramento prioritário), o tráfego de entrada é classificado em quatro níveis de prioridade: alta, média, normal e baixa (high, medium, normal e low). Os pacotes não classificados são marcados, por default, como normal. Fig. 3.6: Operação do enfileiramento Priority Queueing [VoIP_Ramon.pdf, p.24] A utilização deste método requer um cuidado especial, pois como visto acima os pacotes que tem prioridade, tem preferência absoluta, isto pode causar atrasos e aumento de jitter nas aplicações com menos prioridade além de poder acontecer dos pacotes nunca serem enviados. 60

61 Fig. 3.7: Filas Priority Queuening [VoIP_Ramon.pdf, p.24] Podemos classificar o tráfego de uma fila PQ por protocolo, interface de entrada ou lista de acesso. Custom Queueing O algoritmo da fila CQ (Custom Queueing) permite especificar uma percentagem da banda para uma determinada aplicação (alocação absoluta da banda). A banda reservada é compartilhada proporcionalmente, no percentual pré-definido, entre as aplicações e os usuários. O restante da banda é compartilhado entre os outros tipos de tráfego. [VoIP_Ramon.pdf, p.25] 61

62 Fig. 3.8: Operação do enfileiramento Custom Queueing [VoIP_Ramon.pdf, p.25] O algoritmo CQ controla o tráfego alocando uma determinada parte da fila para cada fluxo classificado. As filas são ordenadas ciclicamente num esquema round-robin, onde, para cada fila, é enviado a quantidade de pacotes referente à parte da banda alocada antes de passar para a fila seguinte. Associado a cada fila, há um contador configurável que estabelece quantos bytes devem ser enviados antes da passar para a próxima fila. [VoIP_Ramon.pdf, p.25] Fig. 3.9: Filas Custom Queueing [VoIP_Ramon.pdf, p.25] Até 17 filas podem ser definidas, mas a fila zero é reservada para mensagens do sistemas como sinalização, keep-alive, etc. A classificação CQ pode ser feita por endereço 62

63 fonte ou destino, por protocolo (IP, IPX, Appletalk, SNA, DecNet, etc), por precedência IP, por interface de entrada e ainda por listas de acesso. Comparação entre os Métodos de Enfileiramento Tabela 3.1: Métodos de Enfileiramento [VoIP_Ramon.pdf, p. 26] Na tabela acima podemos ver um breve resumo sobre os métodos de enfileiramento. Deve-se dar uma atenção especial a esta parte já que estas são as diretrizes básicas a serem consideradas no início de um projeto VoIP, porém não se deve esquecer de também analisar os próprios aspectos do projeto, como por exemplo, largura de banda disponível, tipo de roteamento, etc.). Detecção RED e WRED Detecção RED (Random Early Detection Detecção Randômica Antecipada) é um mecanismo de congestion avoidance ou seja serve para prevenir e impedir o congestionamento. Atua para evitar picos de tráfego, através de uma análise antecipada do tráfego. Ao constatar irregularidades pode tomar várias decisões como, por exemplo, descartar pacotes, indicar à fonte para que reduza a taxa de transmissão. 63

64 Detecção WRED (Weighted Random Early Detection Detecção Randômica Antecipada Balanceada) é uma implementação Cisco que adiciona às funcionalidades RED a classificação de pacotes por precedência IP. Fig. 3.10: Funcionamento do WRED [VoIP_Ramon.pdf, p. 26] PROTOCOLO RTCP O RTCP (Real Time Control Protocol Protocolo de controle em Tempo Real) [RFC 1889, 1996] foi criado pelo IETF para auxiliar o RTP. É usado para transmitir aos participantes, de tempos em tempos, pacotes de controle relativos a uma sessão RTP em particular. Esses pacotes de controle podem incluir informações a respeito dos participantes e informações sobre o mapeamento dos participantes em suas fontes de fluxo individuais. [Telefonia IP, p. 14] Funcionalidade do RTCP participantes: O protocolo RTCP é funcional pois, provê informações adicionais sobre seus 64

65 Retorno de informações de Qualidade de Serviço (QoS): Receptores podem retornar informações sobre atraso, jitter, e perdas, que pode ser usadas para adaptar a aplicação, como por exemplo alterar o vocoder que está sendo utilizado. Sincronismo Intermídia: Necessário para sinronizar diferentes fluxos, como áudio e vídeo, caso sua origem seja de servidores diferentes. Identificação do usuário: , nome, organização, etc. O RTCP necessita que as informações citadas sejam enviadas periodicamente, no entanto sabe-se que este envio de informações por parte dos participantes, consome em média 5% de largura de banda, portanto deve ser de suma importância o controle sobre a taxa de envio de pacotes, para que assim possa-se evitar congestionamento entre outros problemas. O mesmo endereço utilizado pelo RTP é usado pelo RTCP, porém em portas diferentes. Nem todas as aplicações RTP utilizam RTCP, que não é indispensável para as aplicações. [VoIP, p.19] Pacote RTCP Um pacote RTP é um pacote de controle constituído de um cabeçalho fixo seguido por elementos estruturados variando de acordo com o tipo de pacote RTCP. - SR (Sender Reports): contém informações de transmissão e recepção para transmissores ativos; - RR (Receiver Reports): contém informações de recepção para ouvintes que não sejam também transmissores ativos; - SDES (Source Descriptions): descrevem vários parâmetros da fonte, inclusive o CNAME; - BYE: enviado por um participante quando ele abandona a conferência; - APP: funções específicas de uma aplicação; 65

66 Octet Version P Reception report count 1 Packet type 2 Length 3-4 Fig. 3.11: Protocolo RTCP [Protocols] RTCP structure deve ser 2 ; Version - versão: espaço reservado para indicação da versão do protocolo. O valor P padding: indica que o payload sofreu enchimento para fins de alinhamento. Devese lembrar que o último octeto dos dados de preenchimento deve conter o número de octetos usados para preenchimento. Apenas o ultimo pacote do pacote composto RTCP prescisa receber preenchimento, uma vez que o pacote composto é encriptado como um todo, caso necessário; Reception Report Count - Contador de Relatório de Recepção: o número de blocos de relatório (reception blocks) presentes no pacote SR. O valor 0 é válido. questão. Packet Type Tipo de pacote: serve para identificar qual é o pacote RTCP em Lenght - comprimento: indica o comprimento do pacote RTCP em palavras de 32 bits menos um, incluindo o cabeçalho e qualquer informação de preenchimento. [RTP_RTCP.pdf, p.18] PROTOCOLO CRTP (Compressed Real-Time Protocol) Um dos problemas relacionados à voz sobre IP é a utilização da largura de banda disponível. Para tentar minimizar este problema foram criados protocolos que se relacionam com a voz transmitida nas chamadas, estes protocolos tentam realizar ao máximo uma 66

67 compressão de dados, para que assim possa-se trafegar mais dados na banda disponível ou ter uma maior banda para trafegar os dados desejados, também usam técnicas de fragmentação e interleaving para se obter um sinal de voz com maior qualidade. O protocolo CRTP (Compressed Real-Time Transport Protocol) comprime o cabeçalho do pacote RTP, que transporta o tráfego de voz. 20 bytes 8 bytes 12 bytes 20 bytes 40 bytes Fig. 3.12: Encapsulamento de pacote VoIP. [VoIP_Ramon.pdf, p. 27] A partir da figura acima podemos ver para se transportar todos esses dados usa-se muita largura de banda, por isso o uso do protocolo CRTP, este protocolo comprime todo o cabeçalho de 40 para 2 Bytes. Seu funcionamento é muito simples, o CRTP primeiramente classifica o tráfego total que esta sendo enviado, em segundo lugar separa o que for RTP para que ocorra a compressão. A parte RTP passa pelo compressor e novamente é anexado aos dados para serem transmitidos. PROTOCOLO IEEE 802.1p priority queueing. A relação entre o protocolo IEEE 802.1p e qualidade de serviço está relacionada a questão de QoS em redes locais. Até agora somente nos preocupamos em analisar a QoS fima-fim, porém esquecemos de visualizar o comportamento dos pacotes de áudio e vídeo dentro das LANs (Local Área Network Rede Local). Por isso a partir de agora analisaremos como obter QoS de, por exemplo, um pacote enviado de um telefone ip até que este pacote alcance a rede de longa distância e chegue à rede remota com a QoS que a aplicação requer, ou seja, o protocolo 802.1p. O protocolo 802.1p define 8 níveis de prioridade de usuários, através de um rótulo (user_priority) de 3 bits que é transmitido no quadro ethernet. 67

68 No caso do pacote enviado pelo telefone IP, este pacote foi primeiro setado no telefone IP com sua precedência, em segundo o pacote chega ao switch, que pode ser compatível ou não com o protocolo 802.1p, caso seja compatível, o switch classificará o quadro ethernet, priorizando os de maior classe, caso não seja compatível, o switch ignora os rótulos e o pacote não sofrerá nenhum tratamento especial, em terceiro o pacote chega ao roteador que classifica o quadro ethernet e mapeia o nível de prioridade 802.1p na precedência IP correspondente, por ultimo, quando o pacote já alcançou a rede de longa distancia, este terá um tratamento de acordo com as várias técnicas de QoS já apresentadas. PROTOCOLO RSVP RSVP (Resource Reservation Protocol Protocolo de Reserva de Recursos) é um protocolo de sinalização, que permite ao equipamento (host e/ou roteadores) requisitar um nível específico de qualidade de serviço para sua aplicação. Também é utilizado na entrega de requisições de QoS de roteadores para roteadores entre outros. As requisições do protocolo RSVP, sempre que possível, provêem um nível de QoS solicitado pelo equipamento (host), isto porque suas requisições fazem reservas de recursos na rede. Fig. 3.13: Protocolo RSVP em Máquinas do Usuário e Roteadores. [RNP-RSVP] 68

69 Embora o protocolo RSVP se favoreça dos protocolos de roteamento para determinar a rota a ser seguida pelos pacotes da origem até o destino, ele não é um protocolo de roteamento. Através dessas técnicas utilizadas pelo RSVP ele ë capaz de operar tanto em modo unicast como em modo multicast, apenas devemos ressaltar que o RSVP faz a reserva de recursos em um único sentido (simplex), tratando assim distintamente receptores e transmissores, operando juntamente com a camada de transporte. Fig. 3.14: Camada de atuação do Protocolo RSVP [RNP-RSVP] Todas as mensagens RSVP apresentam um cabeçalho em comum bits Ver Flags Message type RSVP checksum Send TTL (Reserved) RSVP length RSVP header structure Fig. 3.15: Cabeçalho RSVP [Protocols] Os campos do cabeçalho do protocolo RSVP são descritos abaixo: Ver (Versão): número da versão do protocolo. Flags: Nenhum flag está definido ainda. Message type (Tipo de mensagem): identifica o tipo de mensagem RSVP que está sendo enviada. RSVP Checksum: checksum. Send TTL: O valor do IP TTL com o qual a mensagem foi enviada. 69

70 RSVP length: comprimento total da mensagem RSVP em bytes, incluindo o cabeçalho e os objetos que seguem. Mensagens RSVP O RSVP troca constantemente várias mensagens entre as aplicações e os equipamentos para assim prover qualidade de serviço. As principais mensagens RSVP são PATH e RESV. A mensagem PATH constrói o caminho pelo qual as mensagens RESV irão passar efetuando as reservas de recursos. A operação básica do protocolo RSVP é: - A fonte especifica as características do tráfego a ser transmitido, através de parâmetros do algoritmo Token-Bucket. Esta informação é transportada no objeto Sender Tspec. - O RSVP da fonte envia uma mensagem PATH ao destino (ou destinos) contendo a especificação do tráfego feito pela fonte. A rota a ser seguida pela mensagem PATH é definida pelo algoritmo de roteamento, e não pelo RSVP. - Cada roteador RSVP-capaz ao longo da rota estabelece um "path-state" que inclui o endereço do roteador RSVP-capaz imediatamente anterior (roteador que enviou a mensagem PATH - upstream). Cada roteador envia seu endereço ao vizinho posterior (downstream) através do objeto RSVP_HOP. Os roteadores podem incluir na mensagem PATH informações sobre os recursos disponíveis e o atraso aproximado que ele irá introduzir, através do objeto ADSpec. Assim, em qualquer ponto ao longo da rota, a mensagem PATH contém o endereço IP do roteador vizinho (upstream) e pode conter informações de capacidade e atraso aproximado que cada nó irá introduzir. - Para fazer a reserva de recursos, o receptor envia uma mensagem RESV (requisição de reserva) na direção da fonte, contendo a especificação da qualidade de serviço requisitada para o fluxo de dados (objeto FlowSpec). A mensagem RESV vai do receptor à fonte através do mesmo caminho percorrido pela mensagem PATH. Isto é possível porque cada roteador armazenou o endereço do vizinho (na direção da fonte) recebido na mensagem PATH. - Cada roteador RSVP-capaz ao longo da rota (upstream), ao receber a mensagem RESV, utiliza um processo de controle de admissão para autenticar a requisição e alocar os recursos necessários. Se a requisição não pode ser satisfeita (devido à insuficiência de recursos, por exemplo), o roteador retorna uma mensagem de erro ao receptor (origem da 70

71 mensagem RESV). Se a requisição for aceita, o roteador envia a mensagem RESV ao próximo roteador a upstream. - Quando o último roteador (mais próximo da fonte) recebe a mensagem RESV e aceita a requisição, ele envia uma mensagem de confirmação ao receptor. - O RSVP opera com o conceito de soft state, o que significa que o transmissor e o receptor devem enviar periodicamente mensagens de PATH e RESV para revalidar (ou atualizar) as reservas feitas. Esta característica permite reação dinâmica a alterações ocorridas na fonte do fluxo, nos parâmetros de QoS estabelecidos pelo receptor, ou na rota. [ PARÂMETROS QUE INFLUENCIAM NA QoS DA TECNOLOGIA VoIP Ainda hoje existem pessoas defendendo que os usuários preferem trocar qualidade por preço, no entanto existem outras pessoas que defendem que sem uma qualidade mínima este serviço de voz sobre ip não irá se consolidar. São vários os obstáculos percorridos para que se possa garantir qualidade de serviço em redes IP: Atraso É o tempo gasto por um pacote para ir da origem ao seu destino. Sobre voz, significa dizer que é o tempo que a voz leva do momento que é pronunciada até o momento em que é produzida. Em redes não ponto a ponto o atraso implica no somatório dos atrasos inseridos pela rede e pelos equipamentos. 71

72 Fig. 3.15: Transmissão e Recepção de pacotes. [Inatel, p. 11] Este atraso é decorrente de vários aspectos como, por exemplo, qualidade do meio de transmissão, algoritmos utilizados para codificação de voz e supressão de silêncio, estes aspectos atingem diretamente a QoS. Para o usuário este atraso se reflete da seguinte forma: o locutor irá perceber um intervalo entre suas falas igual a duas vezes ao atraso. Este tempo recebe o nome de roundtrip, que corresponde a duas vezes o atraso. Tabela 3.2: Classificação do atraso. [VoIP_Ramon.pdf, p.29] A figura acima determina a classificação do atraso segundo o ITU-T, para os valores que são ou não aceitáveis para o usuário. O atraso final, percebido pelo usuário, é na verdade gerado por uma série de outros pequenos atrasos: - Atraso de formação de pacote: É o tempo necessário para o preencimento do pacote de voz a ser enviado. Estes atrasos são da ordem de 20 a 30 ms. - Atraso de rede: Tempo necessário para o transporte pela rede do pacote da origem até o destino. Este tempo é variável pois depende da carga na rede. Tanto o computador de origem e/ou destino como o gateway são providos de um mecanismo de formação do pacote e outro correspondente para reprodução de voz. 72

73 Fig. 3.16: Atraso na formação de pacotes. [VoIP_Ramon.pdf, p.29] A figura acima ilustra os responsáveis pelo atraso na formação de pacotes e a figura abaixo mostra o atraso em cada etapa da transmissão. Fig. 3.17: Atraso em cada etapa da transmissão. [gta-alexandre-ufrj] 73

74 Eco Eco é um fenômeno físico que se realiza através da repetição dum som. É causado devido ao atraso, se o atraso fim-a-fim for maior que 25 ms, deverá haver um mecanismo para se cancelar o eco. Por que 25 ms? Porque este é tempo que o ser humano suporta (confunde-se com o som da própria voz) ouvir sua própria voz, sem que esta cause desconforto a ele. Nas redes de telefonia tradicionais o eco ocorre devido a um decasamento de impedância nas híbridas utilizadas para conversão dos quatro fios do nó de comutação para os dois fios do cabo telefônico tradicional. Sobreposição do Locutor Sobreposição do locutor ocorre quando o locutor A fala algo para B, no entanto a mensagem de A leva muito tempo para chegar em B. B que ainda não sabe que A o enviou uma mensagem, envia uma mensagem para A. Esta demora de B na escuta da fala de A, e o início da conversação de B sem antes ter ouvido a mensagem de A caracteriza a sobreposição do locutor. Esta sobreposição do locutor ocorre também devido ao atraso, sendo que para se evitar este tipo de falta de QoS, o atraso deve ser inferior a 400 ms, sendo recomendável pelo ITU-T o limite de 200 ms. Jitter Jitter significa a variação do atraso da transmissão das informações. É causado pelas variações no tráfego e alterações no roteamento. 74

75 Fig. 3.18: jitter [Inatel, p.12] Este problema é tratado através da supressão de jitter, isto significa que é necessário um armazenamento de pacotes por um tempo superior ao maior jitter observado, no entanto essa resolução gera um novo atraso, o atraso de supressão de jitter. Perda de Pacotes A perda de pacotes significa que um pacote enviado não conseguiu atingir seu destino e isto implica na perda de qualidade para a aplicação, sendo que esta qualidade tem seu limite variado de aplicação para aplicação. Estas perdas são causadas pelo descarte de pacotes ocasionado pelos congestionamentos freqüentes em redes ip, atrasos excessivos e erros na tecnologia de transporte. Umas das soluções seria a utilização de protocolos de transporte confiáveis como, por exemplo, o TCP, no entanto os atrasos gerados pelo seu uso tornam-no inutilizável para este tipo de aplicação. Portanto até o presente momento a perda de pacotes é inevitável, isto reflete significativamente na QoS de VoIP. SOLUÇÕES PARA GARANTIA DE QoS EM REDES IP Vários são os problemas percorridos pela QoS para se atingir um nível aceitável, e através de várias técnicas podemos hoje dizer que sim, nós conseguimos chegar a um nível aceitável em transmissões VoIP. 75