Telefonia Voip

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 2005 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

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

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

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

À 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

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

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. disadvantages, however minimized, today what

The advantages are innumerable and the 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

Sumário

REDES DE TRANSMISSÃO DE VOZ SOBRE IP ............................................................. 15 HISTÓRIA DO SURGIMENTO DAS REDES VOIP ...................................................... 15 LIGAÇÃO TELEFÔNICA ATRAVÉS DE REDES IP .................................................... 17 VANTAGENS DA TRANSMISSÃO DE VOZ SOBRE IP.............................................. 17 ARQUITETURA DAS REDES VOIP ............................................................................. 18 SERVIÇOS DA REDE VOIP .......................................................................................... 19 OBSTÁCULOS PARA CONSOLIDAÇÃO DA REDE VOIP ......................................... 20 PROTOCOLOS DE SINALIZAÇÃO .................................................................................. 20 H.323............................................................................................................................... 21 Introdução Histórica ..................................................................................................... 21 Componentes da Recomendação H.323........................................................................ 22 Recomendação H.323 para a Arquitetura Protocolar do H.323 ..................................... 24 Vantagens em se utilizar H.323 .................................................................................... 27 Chamada H.323............................................................................................................ 28 SIP ................................................................................................................................... 33 Introdução.................................................................................................................... 33 Características .............................................................................................................. 34 Arquitetura do SIP........................................................................................................ 34 Mensagens SIP............................................................................................................. 36 Chamadas SIP .............................................................................................................. 42 COMPARAÇÃO ENTRE H.323 E SIP............................................................................ 45 PROTOCOLO SDP ......................................................................................................... 46 PROTOCOLOS ENTRE GATEWAYS DE MÍDIA E CONTROLADORES DE MÍDIA 47 MGCP.............................................................................................................................. 47 Comandos MGCP ........................................................................................................ 50 MEGACO........................................................................................................................ 50 Comandos MEGACO................................................................................................... 51 COMPARAÇÃO ENTRE MGCP E MEGACO ............................................................... 51 PROTOCOLO RTP ............................................................................................................. 52 FUNCIONALIDADES DO RTP...................................................................................... 53 PACOTE RTP ................................................................................................................. 53 SESSÃO RTP .................................................................................................................. 55 QUALIDADE DE SERVIÇO .............................................................................................. 56 MODELO BÁSICO DE QoS ........................................................................................... 56 CONGESTIONAMENTO ............................................................................................... 57 Fifo .............................................................................................................................. 57 Fair Queueing............................................................................................................... 58 Priority Queueing......................................................................................................... 60 Custom Queueing......................................................................................................... 61 Comparação entre os Métodos de Enfileiramento ......................................................... 63 Detecção RED e WRED............................................................................................... 63 PROTOCOLO RTCP....................................................................................................... 64 Funcionalidade do RTCP.............................................................................................. 64 Pacote RTCP................................................................................................................ 65 PROTOCOLO CRTP (Compressed Real-Time Protocol)................................................. 66 PROTOCOLO IEEE 802.1p priority queueing................................................................. 67 8

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

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

10

LISTA DE FIGURAS

Fig. 1.1: Arquitetura de uma rede VoIP....................................................................... Fig. 1.2: Arquitetura Protocolar................................................................................... Fig. 1.3: Componentes do padrão H.323..................................................................... Fig. 1.4: Troca de mensagens entre entidades H.323................................................... Fig. 1.5: Arquitetura Protocolar do H.323................................................................... Fig. 1.6: Padrão H.323................................................................................................. Fig. 1.7: Fluxo básico da conexão H.323..................................................................... Fig. 1.8: Negociação de Capacidades H.245............................................................... Fig.1.9: Abrindo canais lógicos................................................................................... Fig. 1.10: Conversação ativa H.323............................................................................. 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 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.............................................................................................................

18 21 24 26 27 27 30 31 32 33 36 37 40 43 44 45 45 46 48 49 50 51 51 55 58 59 60 60 61 62 62 63 64 65 67 68 70 71 71 75 75 77

11

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..............................................................................

42 52 53 64 74

12

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

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

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.

1977 – 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.

1992 - A Internet Engineering Task Force (IETF) realiza a primeira audiocast através da Multicast Backbone on the Internet (MBone), a partir de San Diego.

1992 - Henning Schulzrinne começa a desenvolver o Real-Time Transport Protocol (RTP).

15

1992 - 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.

1995 – O RTP foi publicado como IETF Proposed Standard.

1995 - Steve McCanne e Van Jacobson desenvolveram a vic, uma aplicação que utiliza o codificador normalizado H.261.

1995 - 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.

1996 - É publicada pela International Telecommunications Union (ITU) a primeira versão da recomendação H.323 [H.323, 1996].

1996 - É prestado pela Delta Three o primeiro serviço comercial de Telefonia sobre IP, seguindo-se a Net2phone, iBasis e Telematrix.

1996 – A Microsoft lança o seu primeiro sistema de conferência sobre redes de pacotes. O Microsoft NetMeeting v1.0.

1999 – 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

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

- 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

- 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.

- Gateways: permitem interligar duas redes que não usem a mesma tecnologia de comunicação.

- 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

- 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

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

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 2003. 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

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

(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.255.0 (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.225.0 (Q.931) é usada devido à

24

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.225.0 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.245. 25

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.450.2 define o serviço adicional de transferência de chamada (call transfer).

26

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

Interoperabilidade de equipamentos e aplicações: O H.323 permite que haja comunicação (interoperabilidade) entre equipamentos e aplicações de diferentes fornecedores.

Independência de plataforma: O H.323 pode operar sob qualquer hardware ou sistema operacional.

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

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.225.0. 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.245. - 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

10.2.3.4

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 10.2.3.4). 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

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

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

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

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 2002.

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

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

Mensagens SIP

Mensagens SIP são codificadas usando a sintaxe de mensagem http/1.1 (RFC 2068). O conjunto de caracteres é o ISO 10646 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

Cabeçalhos

ccc=ddd eee=fff

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

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

de mídia do conteúdo do corpo da mensagem.

[Telefonia IP, p. 126]

Content-lenght: significa o número de octetos do corpo da mensagem. [Telefonia IP, p.126].

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

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

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: [email protected] SP SIP/2.0 CRLF

Via: SIP/2.0/UDP 169.130.12.5

Cabeçalho geral

Call-ID; [email protected] From: <sip:[email protected]> TO: T.A. Watson <sip:[email protected]> Call-ID: [email protected] Cseq: 1 INVITE

Cabeçalho de pedido

Subject: Mr. Watson, come here.

Content-Type: application/sdp

Cabeçalho da entidade

Content-Length: 885 Linha em branco



v=0

Dados SDP

o=bell 53655765 2353687637 IN IP4 128.3.4.5 c=IN IP4 135.180144.94 m=audio 3456 RTP/AVP 0 3 4 5 Fig. 1.13: O formato da mensagem de pedido SIP [Telefonia IP, p.128]

39

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: 100-199: Informação Provisória; 200-199: Sucesso; 300-399: Redirecionamento; 400-499: Erro no cliente; 500-599: Erro no servidor; 600-699: Falha global;

1xx

2xx

Informativo

Pedido recebido, continuando a processar o pedido 100

Tentando

180

Chamando

181

A chamada está sendo retransmitida

182

Colocado na fila

Sucesso

A ação foi recebida, entendida e aceita com sucesso 200

3xx

4xx

Redirecionamento

OK 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

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

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

SIP/2.0 302 Moved temporarily

Linha de status

From: sip: [email protected] To: sip: [email protected]; tag=2332462

cabeçalhos

Call-ID: [email protected] Location: sip:[email protected] Expires: Wed, 29 jul 1998 9:00:00 GMT Cseq: 1 INVITE 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

2002.

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

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

Troca de informações

Fig. 1.15: Chamada ponto-a-ponto SIP [Telefonia IP, p. 119]

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

A

B Troca de informações

BYE sip: [email protected] SIP/2.0 v: SIP/2.0/UDP 192.168.7.2:3456 i: [email protected] From: sip:[email protected] To: sip: [email protected] Cseq 2 BYE SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.7.2:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] 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

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/2.0 486 Busy Here Via: SIP/2.0/UDP 192.190.132.31:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] Cseq 1 INVITE ACK sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.190.132.20:3456 Call-ID: [email protected] From: sip: [email protected] To: sip: [email protected] 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

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

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

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

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

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

Comandos MEGACO

Tabela 1.2: Comandos MEGACO. [Unisal]

COMPARAÇÃO ENTRE MGCP E MEGACO

51

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

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.

Liberdade no controle da sessão: permite aos participantes trocarem informações pessoais.

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

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.225.0 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

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

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

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

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

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

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

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

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

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

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

O protocolo RTCP é funcional pois, provê informações adicionais sobre seus participantes:

64

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: e-mail, 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

0

1

2

Version

P

3

4

5

6

7

Octet

Reception report count

1

Packet type

2

Length

3-4

RTCP structure

Fig. 3.11: Protocolo RTCP [Protocols]

Version - versão: espaço reservado para indicação da versão do protocolo. O valor deve ser ‘2’;

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.

Packet Type – Tipo de pacote: serve para identificar qual é o pacote RTCP em questão.

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

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

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

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.

4 Ver

8 Flags

Send TTL

16

32 bits

Message type

RSVP checksum

(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

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

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. [http://www.rnp.br/newsgen/0005/rsvp.html]

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

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

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

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

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

As técnicas utilizadas são as mais variadas possíveis, que vão desde prover qualidade através de reserva de banda, minimização de atrasos de pacotes até eliminação de jitter de atraso. A seguir veremos algumas dessas técnicas.

Dejitter Buffer

Um dos vários problemas sofridos pela VoIP são as variações de atrasos (jitter), e para minimizar ou até mesmo eliminar este problema, usamos uma técnica chamada dejitter buffer, que significa utilizar buffers na recepção de informações. Esta técnica armazena os pacotes recebidos por um certo tempo e adiciona ao pacote um atraso antes de envia-lo ao receptor, desta forma o atraso total dos pacotes fica igual.

Classificar ou Identificar o Tráfego

Na rede atual onde os pacotes de VoIP trafegam, cada tipo de informação recebe um tratamento diferente dos nós da rede. A solução então seria, classificar os tipos de pacotes que estão trafegando na rede. A classificação por si só, somente proverá efeitos quando em conjunto com outras técnicas como, por exemplo, políticas de priorização da transmissão, pois somente o tráfego de pacotes classificados pelos roteadores e switchs não teria efeito algum, o rotedor/switch apenas saberia que o que passou por ali era um pacote classificado como, por exemplo, pacote de voz ou vídeo. Com a adição de outras técnicas, por exemplo, política de priorização da transmissão, o pacote ao chegar a um roteador/switch poderia ser rapidamente passado à frente ou colocado em uma fila de espera. Esta política poderia classificar os pacotes de diferentes formas: informação contida no pacote, porta de destino, MAC, endereço fonte/destino, etc. e esta classificação pode ser feita por dispositivos de borda ou pelos dispositivos de backbone da rede, preferencialmente deve ser feita na rede LAN antes do pacote ser enviado a redde WAN. [cefetrio]

76

Enfileiramento, Priorização e Disciplina de Despacho

Sabe-se que uns dos grandes problemas enfrentados pelas redes IP hoje em dia são os congestionamentos. Para minimizar este problema foram implantados nos roteadores buffers que servem para armazenar temporariamente os pacotes que chegam até ele, estes pacotes armazenados em buffer são colocados em forma de fila. A idéia então da disciplina de despacho é organizar esta fila que é montada pelo roteador, de forma que os pacotes ganhem prioridades uns em cima dos outros, conforme informações que eles estão trafegando. Sendo assim os pacotes de voz teriam prioridade sobre os pacotes de dados, o que levaria a minimizar os atrasos sofridos pelos pacotes de voz, já que estes seriam rapidamente despachados pelo roteador. Várias técnicas de disciplina de despacho são implementadas para se obter uma maior qualidade de serviço em redes que trafegam voz sobre IP, algumas delas são:

Policiamento e Conformação de Tráfego

As funções de policiamento e conformação usualmente identificam as violações no tráfego de uma mesma maneira. Elas diferem, contudo, na forma como elas respondem a estas violações, por exemplo:

- A função de policiamento usualmente descarta o tráfego que não está conforme ou o define como elegível para descarte. - A função de conformação tipicamente atrasa o tráfego em excesso, através de mecanismos de enfileiramento, retendo os pacotes e liberando-os de maneira tal que o fluxo de saída esteja dentro dos parâmetros definidos. [cefetrio]

Fragmentação

Também é característico do tráfego VoIP, a presença de grandes pacotes de dados. A técnica de fragmentação propõe justamente a este tipo de tráfego uma solução que seria, fragmentar pacotes de dados que excedam a um máximo proposto em pacotes menores, sendo estes pacotes menores tratados de forma independente pela rede. Esta técnica eleva vantagens como: diminuição do tempo médio de enfileiramento de pacote, que faz com que o pacote chegue mais rapidamente ao destino, e do desvio padrão

77

deste tempo, que resulta na diminuição do jitter de atraso na rede, o que vem a melhorar a qualidade do sinal. [cefetrio]

SEGURANÇA EM REDES VOZ SOBRE IP

Introdução

Com o desenvolvimento das novas tecnologias, tornou-se possível a evolução dos sistemas de transmissão, o que viabilizou a criação de redes de pacotes muito mais velozes. Todo este desenvolvimento tem permitido a evolução das redes convergentes, que são redes capazes de transportar pacotes de dados e voz digitalizados. Hoje contamos com vários tipos de redes que são capazes de transportar pacotes de dados e voz, por exemplo, redes baseadas em ATM, Frame Relay e TCP/IP. Destas apenas o Frame Relay e o TCP/IP são utilizados com mais freqüência, embora o ATM tenha sido projetado para tal finalidade. O Transporte através da tecnologia Frame Relay e TCP/IP são conhecidos como VoFR e o VoIP. A diferença entre a utilização de tais redes é referente ao seu custo/beneficio. As redes IP, estão associadas a camada 3 no modelo OSI, o que lhe da muitas vantagens, entre elas o baixo custo e capacidade de operação em redes heterogêneas, em contrapartida recebe como desvantagens a qualidade de serviço e questões relacionadas com a segurança. Já as redes VoFR e VoATM, estão associadas com a camada 2 do modelo OSI, que então apresentam como vantagem, maior qualidade de serviço pois requerem redes homogêneas para o tráfego de informações, e como desvantagem, um custo elevado. [MSLAB, p. 2]

78

Ameaças

Hoje, ainda são mínimos os ataques documentados em cima de redes VoIP, talvez pela ainda não familiarização dos “invasores” com os protocolos desta tecnologia. No entanto já é sabido que em um curto espaço de tempo, esta realidade tomará rumos diferentes, isto se deve a vários motivos, um deles é pelo valor das informações que trafegam pelas redes VoIP, e que em mãos erradas poderão causar grandes prejuízos e lucros a diversas pessoas. É importante ressaltar que na convergência das redes de voz com as redes de dados baseadas em TCP/ IP, houve também a convergência das vulnerabilidades inerentes as duas tecnologias. Ou seja, agora, um computador com telefone IP-compatível precisa ser protegido tanto das ameaças relacionadas aos computadores quanto das ameaças relacionadas com a telefonia. Por exemplo, um telefone IP instalado em uma estação de trabalho com o sistema operacional Windows está suscetível às vulnerabilidades do Windows. [MSLAB, p. 3]

Captura de tráfego e acesso indevido a informações

Nas Redes que trafegam voz sobre IP, a voz é transportada juntamente com as informações da rede de dados, encapsulado em pacotes IP, e a captura destes pacotes em uma rede IP através de técnicas de "Sniffing" é relativamente trivial. Hoje já podemos contar com algumas ferramentas que facilitam este trabalho para o usuário, por exemplo, o VOMIT (“Voice Over Misconfigured Internet Telephones”), que utiliza a ferramenta tcpdump do Unix para capturar pacotes de uma conversa telefônica, que está trafegando na rede de dados e consegue remontá-los e convertê-los em um formato comum de áudio (*.wav). Ou seja, tratase de uma espécie de "grampo telefônico" em plena rede de dados. No entanto estas ferramentas estão começando a surgir agora na internet e ainda encontram-se limitadas a alguns padrões existentes, por exemplo, o CODEC G.711 utilizado pela Cisco. Devemos ressaltar que é questão de tempo para que ferramentas mais poderosas se

79

adentrem à internet, já que os mecanismos de transporte de voz, por enquanto, não utilizam criptografia, deixando assim os pacotes vulneráveis à qualquer destas ferramentas existentes. Várias outras técnicas que podem ser ou não mais complexas podem ser utilizadas pelos atacantes para obtenção de acesso indevido às informações que trafegam pela infraestrutura onde se localiza a rede VoIP. Por exemplo, no ataque de “Caller Identity Spoofing” (algo como “falsificação da identidade do usuário que iniciou a chamada”), o atacante induz um usuário remoto a pensar que ele está conversando com alguma outra pessoa, ou seja, finge ser alguém que não é para obter informações sigilosas. Este tipo de ataque requer apenas que o atacante obtenha acesso físico à rede e consiga instalar um telefone IP não autorizado. Outra técnica que pode ser utilizada é a de (“MAC Spoofing”), o atacante deverá conseguir que seu telefone IP assuma a "identidade" de um telefone IP válido da rede empresa. Boas políticas aplicadas nas empresas podem ser uma boa solução quando se pretende evitar estes tipos de ataques, a integridade da rede aumentará ainda mais se for possível combinar as políticas com uma boa administração da rede, por exemplo, sempre obtendo controle de pontos de rede ativos que não estão sendo utilizados. O treinamento e a boa orientação dos usuários destes tipos de rede, culminarão na dificuldade dos atacantes em se aplicar engenharia social, assim seria mais difícil de se induzir alguém que o atacante é quem ele não é. [MSLAB, p. 4]

Código Malicioso

Como já vimos anteriormente, a tecnologia VoIP está presente nas redes convergentes, ou seja, aquelas redes que trafegam dados e voz no mesmo meio físico. Portanto a tecnologia VoIP também esta susceptível às vulnerabilidades da rede de dados. Algumas das vulnerabilidades que também podem afetar as redes de voz, são os conhecidos vírus, “Trojan Horses” e outros tipos de códigos maliciosos que podem vir a infectar os sistemas de telefonia IP baseados em PCs, os “Gateways”e outros componentes críticos da infra-estrutura. Sendo assim, podemos concluir que até mesmo “técnicas” que não surgiram para afetar as redes VoIP, podem causar a paralisação deste serviço. [MSLAB, p. 5]

80

Fraude Financeira, Uso indevido de recursos corporativos

Uma das ameaças às redes VoIP é a ameaça de “Toll Fraud”. Esta ameaça consiste no uso não autorizado dos serviços de telefonia IP ou métodos de fraude para iludir os mecanismos de bilhetagem e cobrança das ligações realizadas. Existem vários métodos para se aplicar esta técnica. Um deles pode ser o uso indevido de um telefone IP para realização de chamadas que sejam contabilizadas como tendo sido originadas pelo endereço do telefone IP de alguma outra pessoa, a qual seria então responsável ate o momento pelos gastos. Um método mais sofisticado envolveria a instalação de um “Voice Gateway” (ponto de convergência entre a redes) falsificado pelo atacante, pois é neste Gateway que passam todas as ligações. Caso o “Voice Gateway” principal não seja comprometido, o atacante deverá tentar instalar na rede um segundo “Gateway” e tentar redirecionar para ele o tráfego destinado ao “host” original. Desta forma, é possivel bloquear, desviar e até mesmo escutar ligações. [MSLAB, p. 5]

Repúdio

Repúdio em relação à tecnologia VoIP tem a ver com a negação, por parte de um usuário que utilizou os serviços de telefonia IP para fazer uma ligação, de que ele tenha realmente feito tal ligação. Isto só poderá ser comprovado com a implantação de algum mecanismo eficiente para autenticação, do contrário, não será possível identificar os usuários dos serviços, nem discriminar quem executou quais chamadas a partir de quais telefones IP. Indisponibilidade de serviços

Devido à utilização da rede de dados para se transportar voz, esta também torna-se vulnerável aos ataques não só destinados à ela como também aos destinados à rede TCP/IP. Um exemplo ao qual ela torna-se vulnerável é ao ataque de DoS ( “Denial of Service”), os

81

quais causam a paralisação dos serviços em redes TCP/ IP, sendo assim esta paralisação afetará “por tabela” os serviços de voz, fax e vídeo que dependam deste transporte. São vários os ataques que podem causar negação se serviço em redes TCP/IP, entre eles podemos citar o “TCP SYN Flood” e suas variações, e também a exploração de falhas nas pilhas de protocolo dos sistemas operacionais, como no “Ping of Death”, “LAND”, “Teardrop” e vários outros ataques que podem tornar os serviços do VoIP indisponíveis. Nas redes VoIP, os equipamentos de PBX (“Private Branch Exchanges”) tradicionais são substituídos por aplicações PBXs IP-compatíveis que são executadas, por exemplo, em servidores Windows NT. Estas aplicações de “Call Management” são críticas para a infraestrutura de VoIP, e no entanto estão sujeitas aos ataques que exploram vulnerabilidades não só das próprias aplicações como também do sistema operacional. [MSLAB, p. 5]

Meios de proteção

A seguir são apresentadas algumas práticas para a implantação de uma estrutura VoIP segura.

Segmentar o tráfego de voz e dados

As segmentações do tráfego de voz e dados podem ser feitas utilizando Switches. Esta segmentação contribui para obtenção de uma melhor QoS além de facilitar a gerência da rede de voz e simplificar sua manutenção. Ainda podemos com isso evitar que o segmento de voz seja alvo de ataques de “eavesdropping” (captura não autorizada do tráfego de conversas telefônicas que trafegam na rede encapsuladas em pacotes IP) realizados com o VOMIT e outras ferramentas semelhantes. Com a implementação da segmentação, vários outros ataques deixam de existir para a rede de voz, como por exemplo, os ataques baseados em TCP/IP que, mesmo destinados a outros alvos que não estejam diretamente relacionados com a infra-estrutura de VoIP, podem tornar estes serviços indisponíveis caso todo o tráfego esteja no mesmo segmento. 82

Por exemplo, os telefones IP normalmente utilizam o protocolo UDP com portas acima de 16384 para sua comunicação. Sendo assim, um ataque de negação de serviços baseado em “UDP Flood” no segmento de dados poderia afetar também os serviços de voz se as redes não estiverem adequadamente segmentadas. Para que se possa melhorar ainda mais os vários aspectos citados da rede de voz, recomenda-se a separação dos segmentos de rede de voz e dados em VLANs distintas. Como por exemplo, em uma instalação de pequeno porte, uma VLAN dedicada ao tráfego de voz seria suficiente, onde seriam instalados o “Call Manager” e os telefones IP. Outros componentes como estações de gerenciamento e sistemas de “Voice/Mail” podem residir no segmento de dados. Já em instalações de grande porte, várias VLANs podem ser criadas, tanto para voz quanto para dados. Por exemplo, os serviços de “Voice/Mail” podem ocupar uma VLAN dedicada. [MSLAB, p. 6]

Controlar o acesso ao segmento de voz com um Firewall especializado

O uso de um firewall especializado servirá para controlar o acesso ao segmento de rede onde está instalado o “Call Manager”, este tem como objetivo, filtrar todo o tipo de tráfego que seja endereçado à rede de voz e não seja necessário para o funcionamento destes serviços. O firewall irá proteger o “Call Manager” de acessos indevidos por parte de telefones IP não autorizados que sejam instalados em outros segmentos. Logo, as portas e protocolos que serão configuradas no firewall irão depender do tipo de solução/fabricante de solução VoIP em uso. Um aspecto importante ao qual deve-se estar atento é ao de que o firewall deve ser compatível com o protocolo H.323. Isto deve-se ao fato de que este protocolo aloca portas de forma dinâmica para canais de áudio, vídeo e dados. Alguns fabricantes oferecem “aplliances” de firewall/VPN customizados para suas tecnologias, como por exemplo o “Contivity Secure IP Services Gateway” da NORTEL. [MSLAB, p. 6]

83

Evitar o uso de aplicações de telefones para microcomputadores (PC-Based IP phones), utilizando preferencialmente telefones IP que suportem VLAN

Não é recomendável a utilização de SoftPhones, convém utilizar telefones IP que suportem VLANs, já que os SoftPhones estão sujeitos a um maior número de ataques que os aparelhos de telefonia IP baseados em hardware. Além do risco de falhas em seu próprio código, as aplicações de telefone IP para PCs estão sujeitas às vulnerabilidades do sistema operacional e também de outras aplicações que residem no computador onde estão instaladas, bem como vírus, worms e outros códigos maliciosos. Já os telefones IP executam sistemas operacionais proprietários com serviços limitados (e portanto menos vulneráveis) . Além disso, como as aplicações de telefone IP para PC precisam residir no segmento de dados da rede, elas são susceptíveis a ataques de negação de serviços (como “floods” baseados em UDP ou TCP) que sejam destinados ao segmento como um todo, e não apenas ao computador em que estão instalados. [MSLAB, p. 7]

Usar endereços IP privativos e inválidos (compatíveis com RFC 1918) nos telefones IP.

Nos telefones IP devem ser utilizados endereços IP inválidos. Esta medida servirá para reduzir a possibilidade de que o tráfego de voz possa ser monitorado de fora da rede interna e para evitar que os atacantes consigam mapear o segmento de voz em busca de vulnerabilidades. Além disto o uso de IP’s inválidos sucumbirá em menores custos. A utilização de endereços IP privativos e principalmente de classes diferentes nos segmentos de voz e dados, de acordo com a orientação do RFC 1918 ( “Address Allocation for Private Intranets”), servirá para facilitar a configuração de filtros e a monitoração. As conexões com redes externas devem utilizar endereços IP válidos fornecidos por um firewall, através do serviço NAT ( “Network Address Translation”) . [MSLAB, p. 7]

84

Configurar os telefones IP com endereços IP estáticos, associados ao MAC Address

A utilização do MAC Address permite a autenticação dos telefones IP ou seja quando um telefone IP tenta obter configurações da rede do “Call Manager”, seu Mac Address pode ser verificado em uma lista de controle de acesso. Caso o endereço seja desconhecido, o dispositivo não receberá a configuração. Caso seja possível, deve-se aplicar endereços IP estáticos para os telefones IP, e associa-los ao “Mac Address” do dispositivo. Sendo assim, cada telefone IP terá sempre o mesmo endereço IP associado ao endereço MAC. Desta forma, para conseguir instalar um telefone IP não autorizado na rede, um atacante teria que forjar tanto um endereço IP válido para o segmento de voz quanto o endereço MAC a ele associado. Alguns aspectos devem ser considerados antes de tal aplicação pois, dependendo das características do ambiente da implantação, a associação entre endereço IP estático e “Mac Address” nos telefones IP pode ser de difícil gerenciamento. [MSLAB, p. 8]

Utilizar servidores DHCP separados para voz e dados

Preferencialmente deve-se utilizar servidores DHCP separados para os segmentos de voz e dados. Sendo assim, os ataques de negação de serviços (DoS) e outros lançados contra o servidor DHCP no segmento de dados não vão interferir com a alocação de endereços IP para os telefones no segmento de voz, e vice-versa, o que aumenta a tolerância da rede. [MSLAB, p. 8]

85

Monitorar os endereços MAC no segmento de voz

A utilização de ferramentas como, por exemplo, o ARPWATCH para monitorar os “MAC Addresses” de todos os dispositivos instalados no segmento de voz trará mais segurança à rede. O ARPWATCH é capaz de registrar alterações não autorizadas na associação entre endereço IP e endereço MAC. [MSLAB, p. 8]

Implementar mecanismos que permitam autenticar os usuários dos telefones IP

Se a tecnologia em uso atualmente suportar, convém implementar os recursos de autenticação dos usuários dos telefones IP, além de autenticar apenas os dispositivos através de seus endereços MAC. Hoje já podemos encontrar com certa facilidade, alguns modelos de telefones IP que exigem do usuário um “login” e uma senha ou número de identificação (PIN) válidos para que possam utilizar o dispositivo. Este tipo de autenticação reduz os riscos de uso indevido dos recursos da rede de voz, e permite maior rastreabilidade no uso dos serviços, além de um certo nível de não repúdio. Algumas aplicações de telefone IP para a plataforma Windows suportam autenticação integrada ao sistema operacional, enquanto outros modelos utilizam uma combinação de nome de usuário / PIN. Em qualquer caso, as senhas utilizadas devem ser trocadas periodicamente e devem ser de difícil dedução. [MSLAB, p. 8]

Implementar um sistema IDS

É sabido que os sistemas atuais de detecção de intrusão (IDS) ainda não são compostos pelas assinaturas específicas de ataques para os protocolos de VoIP, no entanto 86

eles podem ser úteis para monitorar ataques baseados em UDP e HTTP que podem ser executados contra os componentes da infra-estrutura. Por este motivo, convém que uma aplicação ou aplliance de IDS seja instalado no segmento onde estiver instalado o “Call Manager”, visando a detecção de ataques originados principalmente no segmento de dados, onde estão localizadas as estações de trabalho dos usuários. Naturalmente, é necessário fazer o tunning do IDS para maximizar sua eficiência. Esta operação é dependente do tipo de tecnologia e protocolos de VoIP em uso. De qualquer forma, se tiverem sido separados os segmentos de voz e dados como recomendado, o tráfego esperado no segmento de voz estará obrigatoriamente associado a um número limitado de protocolos e portas, o que facilita a configuração do IDS e reduz o número de falsos positivos. Qualquer tráfego TCP/ IP que não esteja relacionado aos protocolos utilizados pela tecnologia VoIP em uso deve gerar alarmes no sistema IDS. [MSLAB, p. 9]

Fazer o hardening do “host” onde está instalado o call manager

Preferencialmente os atacantes tentam explorar as vulnerabilidades do Call Manager da infra-estrutura de VoIP, devido ao grande número de serviços que podem estar sendo oferecidos por estas aplicações. O Call Manager, por exemplo, normalmente disponibiliza aplicações para controle de chamadas, permite a configuração via Web, dá suporte a serviços de localização de telefones (IP Phone browsing), serviços de conferência, e gerenciamento remoto por SNMP. Por este motivo, convém que sejam implementados procedimentos para a configuração segura (“Hardening“) do servidor onde o Call Manager está instalado. Como recomendações genéricas, convém desabilitar todos os serviços desnecessários, instalar os patches do sistema operacional e um bom antivírus. Os serviços inicializados pelo Call Manager devem utilizar contas de baixo privilégio, e o acesso físico ao servidor deve ser restrito a usuários autorizados. [MSLAB, p. 9]

87

Monitorar a performance e status dos serviços de VoIP

O objetivo deste controle é permitir a monitoração periódica, se possível em tempo real, do desempenho da rede de voz, e detectar instabilidades, atrasos e latências que possam comprometer a performance ou disponibilidade dos serviços. A monitoração pode ser feita através de soluções proprietárias disponibilizadas pelos fabricantes (Cisco, etc) , ou de soluções de mercado como o VoIP Manager da Net IQ ou o VoIP Test Suite da Brix Networks. [MSLAB, p. 10]

Montar uma estrutura de Help Desk capacitada para dar suporte em VoIP

Apenas uma boa implantação da estrutura VoIP não é suficiente para garantir sua perfeita funcionalidade durante o decorrer do tempo, devemos aplicar métodos que ajudaram a manter esta implantação em perfeito funcionamento durante sua existência no ambiente. Para isso deveremos, se possível, ter presente no ambiente que foi implantando a estrutura VoIP uma equipe treinada para realizar configurações necessárias nos equipamentos (Switches, Roteadores e etc) e aplicações utilizados pela rede de voz além de prestar suporte técnico para os usuários. Também é conveniente manter um contrato de Suporte Técnico com algum integrador qualificado, ou com o próprio fabricante dos equipamentos adquiridos. [MSLAB, p. 10]

Restringir o acesso físico

O acesso físico à rede em si deve ser restrito, isto devido à possibilidade de algum atacante conseguir acesso físico indevido na rede e através dessa vulnerabilidade conseguir tirar proveitos. Com acesso à rede física o atacante pode, por exemplo, instalar um telefone IP 88

não autorizado e utilizar técnicas de “MAC Spoofing” e “Caller Identity Spoofing” para enganar os usuários, fazendo-os pensar que estão conversando com alguma outra pessoa, quando na verdade estão conversando com o atacante. Desta forma informações sigilosas poderão ser obtidas através de engenharia social. Naturalmente, o acesso físico indevido também expõe os componentes da infraestrutura de VoIP a ameaças como fraudes, roubo, sabotagem ou danificação acidental ou proposital dos equipamentos, podendo causar a indisponibilidade dos serviços. Por estes motivos, convém que o acesso físico aos dispositivos mais críticos da rede (Switches, Roteadores, Call Manager, Firewalls, etc), seja restrito apenas à usuários autorizados. [MSLAB, p. 10]

Auditar o uso dos recursos

A verificação da qualidade de serviço prestada pelos equipamentos VoIP bem como sua utilização pelos usuários deve ser auditada periodicamente. Para isso devemos manter registros das informações sobre as sessões (data e horário do início e término, duração, origem, destino, etc) além de informações relacionadas a QoS (latência, perda de pacotes, uso de banda, etc).A auditoria pode ser implementada através de aplicações especializadas. Para um auditoria mais prescisa, recomendamos que os usuários utilizem algum tipo de autenticação quando utilizarem os serviços da rede de voz. [MSLAB, p. 10]

Criptografar o tráfego de VoIP

Recomendamos a criptografia de todo o tráfego passante entre o telefone IP e o “Call Manager”. Esta medida tem como objetivo impedir o uso de ferramentas como o VOMIT para violação da confidencialidade das conversações. Um exemplo de criptografia que pode ser utilizada para tal ambiente seria a implantação de um túnel IPSec entre as estações com telefones IP e o “Call Manager”. Para 89

as comunicações externas (matriz com filiais, por exemplo), deve-se considerar a implementação de uma VPN (“Virtual Private Network”) para criptografar o tráfego de VoIP. [MSLAB, p. 10]

Conclusão

Assim podemos entender todos os riscos (telefones IP, roteadores, Switches, Gateways, sistemas de “Voice Mail”, Firewalls e outros) e problemas (delay, jitter, perda de pacotes, “Toll Fraud” ( fraudes de pagamento), IP Phone Spoofing, etc) inerentes pelos quais as redes de voz estão vulneráveis. Compreendemos ainda que estes riscos e problemas aumentam caso a estrutura da rede de voz esteja na mesma estrutura da rede de dados, pois assim a rede de voz herdará todos os perigos das redes de dados (mapeamentos, TCP/IP Denial of Service, exploração das vulnerabilidades dos sistemas operacionais, engenharia social, roubo de identidade e spoofing, etc), isto porque a convergência das redes traz também a convergência das ameaças. É sabido também que um bom sistema de autenticação não só dos dispositivos (telefone IP e etc) como também do usuário é essencial para um perfeito controle do ambiente da rede de voz, evitando assim que ferramentas como o VOMIT possam vir a comprometer a confidencialidade das conversas telefônicas, permitindo acesso indevido a informações sigilosas, além de outros problemas como repúdio etc. Hoje ainda não podemos contar com nenhuma solução completa para as redes de voz, o que poderia vir a fornecer um ambiente mais homogêneo e mais seguro do que os ambientes atuais. No entanto devemos estar cientes de que quando mais separada a rede de dados da rede de voz melhor, e que seguindo as recomendações que surgem sobre segurança VoIP, estaremos minimizando as ocorrências de ameaças ao ambiente, tornando-o cada vez mais seguro. A implantação de um sistema VoIP em qualquer ambiente requer de início um bom planejamento da infra-estrutura, um cabeamento adequado, dispositivos que suportem as demandas de QoS requeridas, uma segmentação apropriada da rede, planejamento de serviços como o DHCP. A implantação de uma Política de Segurança é muito importante, e deve preceder a configuração de Switches, Roteadores, FireWalls, soluções de IDS e outros

90

dispositivos de proteção, cujo acesso físico deve ser restrito a usuários autorizados. O uso de criptografia do tráfego de voz encapsulado na rede IP é recomendado em certos contextos. Os equipamentos (por exemplo, telefones IP que suportem VLAN e soluções que ofereçam recursos de autenticação mais sofisticados) devem ser escolhidos de forma mais crítica para viabilizar um maior nível de segurança, bem como o treinamento do pessoal envolvido na instalação, suporte e auditoria dos serviços. Em alguns casos, até mesmo um plano de “Disaster Recovery” deve ser considerado, tal o impacto que a descontinuidade dos serviços de voz pode trazer para a corporação. Finalmente, é preciso conscientizar os usuários dos serviços VoIP no ambiente corporativo sobre os riscos existentes, já que em muitos casos eles próprios poderão ser responsabilizados pelo uso indevido, fraude e outras ações maliciosas executadas pelos atacantes.

Benefícios da Convergência

Redução de custos Na infraestrutura convergente além de se aproveitar o cabeamento, as operações ficam mais simplicadas, as rotas tem um menos custo devido ao compartilhamento dos circuitos e a rede apresenta maior escalabilidade. [innovagency]

Ganhos de produtividade As redes convergentes apresentam ganho de produtividade pois permite mobilidade, ou seja, conectividade para o usuário onde quer que ele esteja e em qualquer momento, sendo assim as empresas podem aplicar o teletrabalho que aumenta a produtividade em até 50% e a motivação em até 30%. [innovagency]

Melhoria da Eficácia de pessoas e organizações: As pessoas tornam-se mais eficazes perante uma rede convergente pois, as comunicações tornam-se unificadas, a colaboração entre pessoas aumenta consideravelmente, os recursos são alocados de forma otimizada, independente da localização geográfica.

O ritmo do projeto de convergência é importante Processo de melhoria constante Implementação baseada: começar por onde fizer sentido [innovagency] 91

Convergência chegou, e está para ficar ! Não se perspectivam novos desenvolvimentos na voz tradicional (TDM)

Riscos e Inibidores da convergência

Não existem, neste momento, entraves de maior. Benefícios evidentes Tecnologia disponível. [innovagency]

Mas alguns aspectos pertinentes podem atrasar a implementação Salientamos que mesmo com as diversas vantagens apresentadas para se utilizar redes convergentes, é de nosso parecer que sempre que for possível deve-se utilizar circuitos independentes de dados e voz devido a diversas características como, por exemplo: Segurança, Gestão de SLA, QoS & Desenho de rede, Interoperabilidade de “standards”, Existência de know-how interno à organização, Monitorização & gestão da qualidade VoIP.

92

SPIT em geral

1. Origem e significado

A expressão spit teve sua provável origem no artigo publicado por Bruce Schneier na data de 13 de maio de 2005 em seu blog “Schneier on Security”. [schneier]

2. Prejuízos causados pelo spit

São diversos os prejuízos causados pela técnica de spit, entre eles podemos citar:

1. Os custos que o spammer tem para manter sua conexão com a Internet, conta como o provedor, linha telefônica e energia elétrica. Sabemos ainda que quanto mais tempo se permanece on-line, maiores são os custos. No caso dos prejuízos causados pelo spit para os receptores, quem o recebe é obrigado a ficar mais tempo ouvindo aquelas mensagens indesejáveis deixadas no seu correio de voz, o que acaba gerando custos com energia elétrica, conexão com internet além dos prejuízos “psicológicos” (raiva, angustia, stress e etc); [schneier]

2. O segundo prejuízo a ser citado é o tempo. Primeiro porque o receptor é obrigado a ficar mais tempo on-line. Segundo por que se perde um tempo precioso para bloquear cada um dos números telefônicos dos spammers, tempo este que poderia ser utilizado de forma mais útil; [schneier]

3. O terceiro prejuízo fica por conta das enormes dificuldades e prejuízos para provedores e servidores também, visto que quanto mais spit acumulado, maior será o custo de armazenamento e comunicação. Finalizando, o mau uso da Internet poderá retardar o tempo de resposta das conexões. [schneier] 93

3. Envio de spit

O meio mais comum de envio do spit é baseado no telemarketing, o spammer grava a mensagem e através de um método automatizado envia a mesma, em massa para diversos destinatários. Este sistema automatizado é capaz de realizar ligações aleatórias ou seqüenciais e a cada atendimento o sistema dispara a gravação feita pelo spammer.

4. SPIT (spam over IP Telephony), abordagem geral

Um dos problemas previstos a acontecerem nas redes VoIP refere-se a uma técnica já conhecida na telefonia tradicional como telemarketing e suas derivações, em VoIP essa técnica receberá o nome de SPIT. Spit é conhecido como sendo o “spam over IP Telephony”, em outras palavras, spit são as mensagens não solicitadas que chegam por meio de Voz sobre IP (VoIP) aos usuários da tecnologia. Esta é uma tendência derivada do spam, assim como muitas outras, que agora atinge os meios de comunicação de voz sobre ip. O spam sobre telefonia IP é associado hoje em dia por alguns especialistas ao telemarketing, pois assim como o ele o spit poderá/pode nos enviar mensagens indesejáveis, em momentos indesejáveis, com propostas indesejáveis a quaisquer telefones. Logo podemos pensar que o spit por vez pode ainda contar com a vantagem da gratuidade da ligação, o que não ocorre no telemarketing. Devemos assim sobressaltar que este exemplo é apenas uma analogia, pois podemos pensar em ambas as técnicas com o sentido de invasão de privacidade, da insistência em vender ou oferecer algo que o cliente realmente não pediu e nem está interessado. Assim podemos ver o spit como uma técnica promissora pois desperta sentimentos em muitos, pois poderiam agora praticar o telemarketing de forma “gratuita”. Hoje infelizmente não podemos contar com nenhuma ferramenta especializada em combater o spit assim como encontramos ferramentas que combatem o spam. No entanto devemos ressaltar que mesmo as ferramentas especializadas em spam não conseguem elimina-lo completamente, apenas dribla-lo, isto porque na maioria das vezes os e-mails spam ficam armazenados nas pastas de quarentena.

94

Igualmente como o spam o spit irá acarretar problemas, pois também fará uso de recursos computacionais além de sobrecarregar a internet, principal veículo de transporte das redes VoIP. Desta maneira, os filtros ainda são e serão a solução (paliativa) para o spam e o spit. Imaginemos então, por enquanto, as diversas formas de spam como algo do nosso cotidiano que temos que conviver, pois não encontramos solução para ela, assim iremos ate podermos dar a carta final ao spam dando dribles no cotidiano. [cicilini]

SEGURANÇA NOS PROTOCOLOS H.323 E SIP

SIP

Segurança na troca de mensagens

As mensagens SIP devem ser criptografadas por uma série de motivos os quais englobam, por exemplo, no caso se a chave de criptografia de mídia tiver de ser protegida , os pedidos e respostas SDP deverão ser criptografados, deve-se esconder a origem e o destino das chamadas e os campos de informação relacionados, deve-se evitar que o usuário receba mensagens enganosas além do seu uso para contabilidade e tarifação. O protocolo SIP conta com vários sistemas de segurança para se evitar várias ameaças ao ambiente VoIP, como por exemplo, preservação da integridade e confidencialidade, prevenção de ataques que possam vir a desviar mensagens, provocar DoS ou ainda proporcionar a autenticação de atacantes que possam vir a violar a privacidade dos participantes numa sessão. A criptografia das mensagens é a melhor opção de segurança para a sinalização, isto garante a confidencialidade e a integridade das mensagens. Porém o protocolo SIP não permite a criptografia das mensagens ponto a ponto, pois estas podem vir a trafegar por vários outros equipamentos da rede como, por exemplo, Proxy Server cuja função é analisar os pedidos e respostas para que assim possa encaminha-los de forma correta. Naturalmente, o 95

Proxy Server poderá ainda remover ou adicionar informações como, por exemplo, os cabeçalhos Via. No entanto, caso seja necessário tal grau de segurança, será necessário que a segurança seja aplicada em um nível mais baixo, no qual as mensagens deverão ser cifradas entre as entidades SIP e assim poderão permitir aos terminais a verificação da identificação dos servidores destinatários, para os quais são enviadas as mensagens de forma segura, utilizandose apenas de um sistema e autenticação criptográfica. A solução prevista no caso citado a cima é o uso dos protocolos TLS (Transport Layer Security) [RFC 2246, 1999] e IPSEC [RFC 2401, 1998], os quais fornecerão às camadas de transporte e rede um maior nível de segurança, que permitirá a integridade e confidencialidade das mensagens. Podemos também contar com os chamados SIPS URI que permitem o estabelecimento de sessões seguras, garantindo que é utilizado transporte criptográfico (TLS) para entregar as mensagens. A autenticação da identidade dos utilizadores fica por conta do método Digest [RFC 3261, 2002], um método de autenticação que se baseia no esquema de autenticação HTTP Digest, utilizado pelo protocolo HTTP. Este método permite aos utilizadores identificarem-se perante uma entidade através do nome do utilizador e de uma palavra-chave cifrada, utilizando a informação que lhe é fornecida pelas respostas 401 ou 407. Por exemplo, quando um utilizador se pretende registar num Registrar ou enviar um INVITE através de um SIP Proxy, o servidor responde com uma resposta 401 ou 407 indicando que é necessária a sua autenticação e transportando as suas credenciais. Quando o utilizador recebe a resposta formula um novo pedido, que desta vez transporta a informação necessária para confirmar a sua identidade. Este mecanismo de segurança permite evitar ataques em que utilizadores mal intencionados assumem a identidade não autorizada de outros utilizadores; no entanto não garante a confidencialidade e integridade das mensagens. [sIPtel, p. 62]

Segurança da mídia

A criptografia de mídia é especificada pelo SDP [RFC 2327]. O parâmetro k do SDP armazena o algoritmo de segurança em uso bem como a chave. A RFC supracitada define os seguintes formatos: 96

K=clear:

Esse formato refere-se aos algoritmos de criptografia descritos no RFC 1890 (“perfil RTP para conferencias de áudio e vídeo com controle mínimo”). O RFC 1890 descreve primeiro como extrair uma chave a partir de uma pass phrase de uma forma padrão. A pass phrase é colocada em uma forma canônica (espaços em branco no inicio e no fim removidos, caracteres colocados em minúsculo etc.) e, então, dividida em 16 octetos pelo algoritmo MD5. Chaves com menos de 128 bits são formadas truncando-se o sumário MD5. As chaves são extraídas em ordem para os algoritmos que precisam de mais de uma (p. ex.: três chaves para DES triplo). [Telefonia IP, p. 150] O nome do algoritmo em uso é inserido antes da chave e separado dela com uma única barra. Identificadores padrão para os algoritmos mais comuns podem ser encontrados no RFC 1423: ‘DES-CBC’, ‘DES-ECB’; o padrão é DES-CBC. O RFC 1423 também descreve como armazenar parâmetros adicionais necessários para determinados algoritmos, como o vetor de inicialização de 64 bits do DES-CBC, por exemplo: K=clear:DES-CBC/aZ25rYg7/12eR5t6y

K=base64:

O formato é o mesmo que o anterior, mas o base64 é codificado para esconder caracteres não permitidos pelo SDP.

K=prompt

Solicita ao usuário uma chave. O algoritmo padrão é o DES-CBC. [Telefonia IP, p. 150]

Firewalls SIP

Os terminais SIP podem ser configurados para enviar todos os seus pedidos para um servidor proxy SIP, em vez de tentar alcançar o servidor SIP apropriado usando registros 97

DNS. O suporte nativo para o NAT ((Network Address Translation) é uma técnica usada para segurança, bem como para evitar problemas de re-endereçamento) por parte das entidades SIP permite a configuração de sinalização para comunicações de saída sem nenhum requisito específico no firewall. Mas, para os fluxos de mídia, o firewall prescisa estar ciente dos fluxos UDP que chegam, para repassa-los à entidade apropriada. As chamadas que chegam precisam ser tratadas por um proxy de sinalização SIP do firewall. [Telefonia IP, p. 152]

H.323

O H.235 é o responsável pela implementação de segurança nos ambientes H.323. Este protocolo implementa tamanha segurança que hoje em dia torna-se mais difícil escutar uma chamada telefônica H.323 do que “grampear” uma linha telefônica, uma vez que o atacante precisará implementar o algoritmo do codec. Alguns especialistas afirmam que em uma rede protegida pelo H.235, mesmo que o atacante tenha acesso livre à rede IP, este não conseguirá escutar qualquer conversa, além disso o H.235 permite que o terminal chamador esconda o número de destino que está tentando alcançar. [Telefonia IP, p. 64] A segurança implementada pelo H.235 é realizada através do uso de algoritmos de criptografia, que visam manter a privacidade, autenticação e integridade do tráfego da rede. Atualmente o H.235 utiliza duas técnicas principais de criptografia, a criptografia simétrica mais conhecida como criptografia de chave secreta e a criptografia assimétrica ou criptografia de chave pública. Criptografia de chave secreta baseia-se em um método onde destinatário e emissor das mensagens compartilham um “segredo”, que pode vir a ser um algoritmo usado para codificar a mensagem ou uma “chave” usada como parâmetro em um algoritmo bem conhecido. Criptografia de chave publica baseia-se em uma maneira pragmática de se considerar a segurança da informação: algumas informações estão seguras não apenas quando você não sabe como extrair a informação, mas também quando você sabe como extrair a informação, porém você praticamente não pode faze-lo porque isso demandaria tempo demais para executar o algoritmo de extração, mesmo para o mais rápido computador existente. [Telefonia IP, p. 64]

98

SNIFFERS VOIP

Com a convergência das redes telefônicas normais para as redes telefônicas baseadas em pacotes. Muitas necessidades surgiram. Uma dessas necessidades é a de controlar as redes VoIP. É necessidade do administrador de rede, saber estatísticas atuais, momentâneas sobre o tráfego corrente dos pacotes VoIP. Para ajudar esses profissionais, hoje em dia no mercado já é possível contar com algumas ferramentas que os auxiliaram nesta jornada. Essas ferramentas são denominadas Sniffers. O principal papel do sniffer é capturar todo o trafego (entrante/sainte), e trazer dados funcionais à tela do administrador. Com esses dados o responsável pela rede poderá então achar defeitos, monitorar, controlar o comportamento da rede conforme o nível de trafego e/ou realizar uma perícia sobre sua performance. Com isso será possível assegurar a QoS nas redes de voz sobre ip, além de realçalas em todos os níveis e além disso poderá otimizar a gerencia de voz, vídeo e dados sobre uma única rede. E todas essas opções poderão, através de Sniffers, serem realizadas em tempo real. [Sniffer] È possível saber se a rede comporta a demanda de usuários.

Características dos Sniffers VoIP

•

identificam os problemas de rede rapidamente;

•

fornecem análise para uma larga escala de protocolos VoIP;

•

Oferecem análise de problemas, tais como: o perda de pacotes; o atraso de pacotes; o pacotes que chegam fora de seqüência; o duracao das chamadas; o Tempo de resposta de comando.

99

•

Análise completa das camadas de Aplicação e sessão para as conexões VoIP. Para a perfeita funcionalidade deste módulo usase o protocolo Skinny Client Control Protocol (SCCP).

•

Realiza alertas preventivos, sobre possíveis problemas da rede. [Sniffer]

EXEMPLO DE APLICAÇÃO DE SEGURANÇA EM REDES VOIP

Encriptação de VoIP no sistema omnipcx enterprise

A segurança é vista, em alguns casos, como uma entrave à adoção de telefonia sobre IP em detrimento de sistemas de telefonia tradicionais. Para obviar esta realidade a Alcatel desenvolveu, em conjunto com a empresa Thales (fornecedor reconhecido em mercados como a Defesa), uma solução que garante a segurança do tráfego de voz sobre IP, através de mecanismos como autenticação, integridade e encriptação dos fluxos de comunicação. Um nível de segurança, responsável pela encriptação, é colocado entre os componentes da solução OmniPCX Entreprise (Call Server, Media gateways e telefones IP) e a LAN ou a WAN, a partir das quais poderão ser lançados ataques. Este nível é constituído por hardware dedicado, denominado “Call Server Security Module - SSM” e “Media Security Module - MSM”, para protecção do Call Server e das Media Gateways, respectivamente. Os telefones IP, IP- Touch®, suportam este serviço de uma forma nativa . A voz é encriptada utilizando SRPT (secure RTP) através do algoritmo de encriptação AES (modo contador). A vantagem do SRTP é que não introduz “overhead” quando comparado com tráfego não encriptado, simplificando também alguns dos serviços na rede como sejam QoS, detecção de falhas e firewalling. São utilizadas chaves simétricas que mudam em cada nova sessão RTP e são enviadas pelo Call Server para os pontos terminais através de sessões de sinalização encriptadas. A gestão da solução é feita a partir da plataforma OmniVista 4760, podendo ser integrada em clientes com siste mas Alcatel OmniPCX Enterprise. [Alcatel]

100

Conclusão

A segurança deve ser encarada não como um produto mas sim como um conjunto de processos e mentalidades, na qual os equipamentos representam apenas uma das componentes. As empresas devem por isso ter uma estratégia clara na definição de soluções de segurança, no que diz respeito ao desenvolvimento dos seus pro- dutos, bem como dos serviços dispo- níveis quando integrados em redes de comunicações IP. Esta é, a nosso ver, uma estratégia evolutiva procurando acompanhar as constantes necessidades dos merca- dos empresariais.

101

Conclusões

Visto que muito já foi feito pela tecnologia VoIP, podemos dizer que a tecnologia de transmissões de voz sobre IP pode funcionar muito bem sob as infra-estruturas que temos acesso hoje em dia, além de ser uma ótima opção quando pensa-se em redução de custos. Depois de avaliar todas as características que a VoIP apresenta, salientamos que além de todos os serviços oferecidos pelas redes de telefonia tradicionais, ela apresenta muito mais por muito menos. Embora a VoIP esteja em alta e as redes tradicionais em desvantagem, é sabido que a maior concorrente de VoIP são estas mesmas. Essa concorrência é presente na capacidade de as redes tradicionais terem uma disponibilidade elevadíssima em comparação à VoIP, e à sua viabilidade. Apesar da VoIP ainda conter muitos aspectos desfavoráveis como, por exemplo, à ainda pouca qualidade de serviço, outros aspectos vêem à favorecer como, por exemplo, o protocolo SIP, que apresenta nativo em sua ultima versão um ‘bom’ nível de segurança, o que leva à uma grande aceitação da VoIP pelas empresas. Podemos também discursar sobre a consolidação da VoIP que por poucas atualizações, pode vir a ser em pouquíssimo tempo o novo ‘boom’ que a humanidade presenciará depois da internet.

102

Referências Bibliográficas

HERSENT, OLIVER., GURLE, DAVID. E PETIT, JEAN-PIERRE. Telefonia IP. Tradução por Adriano Vilela Barbosa e Hugo Bastos de Paula: Makron, 2002. XAVIER, SIDINEY. Voz sobre IP na PBH. Belo Horizonte: PRODABEL/PUC, 2000. 50p. SOUZA, JOÃO PAULO PEREIRA DE. sIPtel – Um sistema de IPtel com suporte para vídeo utilizando o protocolo SIP. Utad: Universidade de Trás-os-Montes e Alto Douro, 2003. 134p. MARQUES, ALEXANDRE FERNANDEZ. Segurança em Redes IP. 2001. 175p. FERNANDES, NELSON LUIZ LEAL. Voz sobre IP: Uma visão geral. 22p. Disponível em: . Acesso em: 03 maio 2005. QUEIROZ, DANIEL CRUZ DE. Voz sobre IP em Redes Corporativas. Fortaleza: Universidade de Fortaleza/UNIFOR. 2002. 63p. GOMES, CARLOS HENRIQUE VICENTINI. Voz sobre IP. Santa Rita do Sapucaí: Instituto Nacional de Telecomunicações/INATEL. 34p. Disponível em: http://www.inatel.br/posgraduacao/redes/download/VoIP_Pos_Graduacao_Brasilia.pdf Acesso em: 22 abril 2005 LEÃO, OSMAR RIBEIRO., Regras para proteção de redes IP. Universidade Católica do Salvador. 2001. 118p. GALVÃO, MÁRCIO., ZATTAR, ALEXANDRE., Aspectos de segurança em redes voz sobre IP, MSLAB (Módulo Security Lab), 2003, 13p. YOSHIOKA, SERGIO., Aspectos de Segurança em Telefonia IP, 2004, 62p. D. RICHARD KUHN, THOMAS J. WALSH, STEFFEN FRIES., Security Considerations for Voice Over IP Systems, 2005, 99p. < http://www.voip.nce.ufrj.br/index_curso_rnp.htm > acesso em: 20 março 2005 < http://www.packetizer.com/voip/h323/ > acesso em: 28 março 2005 < http://www.packetizer.com/voip/sip/ > acesso em: 28 março 2005 < http://www.pr.gov.br/batebyte/edicoes/1999/bb90/redes.htm > acesso em: 2 abril 2005 < http://www.rnp.br/newsgen/0111/h323.html > acesso em: 6 abril 2005-06-03 Acesso em: 12 abril 2005

103

< http://www.gta.ufrj.br/grad/00_2/alexandre/VoIP.html > Acesso em 28 maio 2005 Acesso em: 18 maio 2005 < http://www.voip.nce.ufrj.br/courses/nce/aula8.pdf > Acesso em: 19 maio 2005 < http://www.am.unisal.br/graduacao/ansi/pdf/palestra-ssi-2004.pdf > Acesso em: 20 maio 2005 Acesso em: 22 maio 2005

< http://www.protocols.com/pbook/h323.htm#RTCP > Acesso em: 25 maio 2005 < http://www.rnp.br/newsgen/0005/rsvp.html > Acesso em: 25 maio 2005 < http://www.protocols.com/pbook/tcpip4.htm > Aceso em: 25 maio 2005 < http://www.suigeneris.pro.br/direito_dci_ajspamrm.htm > Acesso em: 20 setembro 2005 < http://www.schneier.com/blog/archives/2005/05/combating_spam.html > Acesso em: 27 setembro 2005 < http://www.4linhas.com.pt/revistas%20PDF/RevUp-004.pdf > Acesso em: 10 outubro 2005 < http://www.voipsa.org > Acesso em: 22 outubro 2005 < http://www.sniffer.com > acesso em: 20 agosto 2005 Acesso em: 18 agosto 2005

< http://www.cicilini.com.br/ > Acesso em: 23 agosto 2005

< http://www.alcatel.com.br/ > Acesso em: 15 novembro 2005

Acesso em: 13 novembro 2005

104