Boas práticas de infra-estrutura de rede para suporte à voz
1. Introdução
Este documento relaciona boas práticas de infra-estrutura de rede para suporte a voz e vídeo, quando aplicável.. As recomendações apresentadas devem ser encaradas como uma diretriz básica para adequação da rede a fim de obtenção do esperado nível de qualidade que a plataforma InstantVoice ® oferece.
2. Requisitos para tráfego de voz e vídeo
Para se transportar voz interativa e vídeo com adequado nível de qualidade deve-se atentar para os requisitos de rede exigidos em termos de consumo de banda, perdas na rede, atraso e variação de atraso. Esta seção descreve estes requisitos.
2.1. CODEC
Como o próprio nome sugere, o recurso é usado para COdificar e DECodificar os sinais de transmissão de dados. Os codecs são usados para converter um sinal analógico de voz em uma versão codificada digitalmente. Independente da forma utilizada, seja através de um hardware ou software, o codec é responsável por implementar um algoritmo que comprime os sinais modificando os sinais analógicos em uma sequência de bits.
Codecs variam na qualidade do som, banda passante necessária e requisitos computacionais. Cada serviço, programa, telefone ou gateway, tipicamente, suporta vários codecs diferentes e quando vão falar um com outro negociam que codec vão usar.
2.2. Banda
A banda requisitada para cada fluxo de voz depende diretamente do codificador e do meio de transporte utilizados. A tabela 1 apresenta o consumo de banda requisitado, por canal de voz, utilizando codificadores usuais nos principais meios de transmissão:
Tabela 1: Consumo de para codificadores usuais
A plataforma InstantVoice utiliza preferencialmente os seguintes codificadores para o tráfego de voz (consulte a equipe de suporte para alterações da configuração padrão):
“Softphone” Instant Phone: preferencialmente G.711 em rede local;
Ramais analógicos: preferencialmente G.711 em rede local, com opção de G.729 para ramais remotos;
Ramais IP (telefone IP): preferencialmente G.711 em rede local, com opção de G.729 para ramais remotos;
2.3. Perdas na rede
A perda de pacotes, normalmente decorrente de congestionamentos na rede, é uma das principais causas da má qualidade de voz. Pontos de congestionamento (gargalos) devem ser identificados e tratados com priorização do fluxo de voz.
A perda de pacote não deve ultrapassar a taxa de 1% no pior caso. É importante notar que codificadores mais robustos (como, por exemplo, o G.711) possuem maior tolerância a perdas que codificadores menos robustos (como, por exemplo, o G.729 e o GSM), entretanto, codificadores mais robustos normalmente requisitam maior consumo de banda.
2.4. Atraso
O atraso demasiado acarreta na perda de interatividade da conversa. Recomenda-se que o atraso máximo na rede em um sentido não ultrapasse 100 ms.
2.5. Variação do atraso (Jitter)
A variação do atraso pode acarretar em perdas nos buffers de compensação de jitter dos dispositivos VoIP e alta degradação na qualidade da voz. É recomendado que a variação do atraso não ultrapasse 20 ms.
Uma variação de até 30 ms é aceitável em algumas situações onde o atraso da rede é baixo, possibilitando que os buffers de compensação de jitter trabalhem com tamanhos maiores.
3. Políticas de priorização de tráfego
Políticas de priorização de tráfego são comumente chamadas de “políticas de gerenciamento de filas”, já que agem nas filas dos equipamentos de rede de forma a favorecer fluxos de maior prioridade em detrimento aos fluxos de menor prioridade.
3.1. Identificando onde as políticas de priorização de tráfego devem ser aplicadas
É importante notar que tais políticas só são efetivas quando aplicadas em pontos onde filas são geradas. Não faz sentido priorizar o tráfego onde não há fila.
Logo, ao se projetar uma rede com priorização de tráfego, um dos passos mais importantes é a identificação dos pontos de gargalo onde as políticas de gerenciamento de filas devem ser aplicadas.
Nas figuras nas seções 2.1.1, 2.1.2 e 2.1.3 são ilustrados três cenários usuais de redes. Em cada um dos cenários são apontados os pontos de gargalo onde a aplicação de políticas de priorização de tráfego é efetiva.
3.1.1. Cenário 1 – Acesso à WAN
No cenário ilustrado na figura 1 podemos observar um roteador com uma interface de rede local (Fast Ethernet com 100 Mbps) e uma interface WAN de baixa velocidade (2 Mbps).
É importante observar que no sentido WAN para LAN a geração de filas não é caracterizada, já que o roteador recebe o tráfego da WAN em uma velocidade menor que é capaz de enfiar para a LAN.
Entretanto, no sentido LAN para WAN, é possível observar uma tendência a geração de filas, já que o roteador tende a receber da LAN mais tráfego do que é capaz de repassar para a WAN.
Figura 1: Cenário 1 - Acesso a WAN
Figura 1: Cenário 1 - Acesso a WAN
3.1.2. Cenário 2 – Interligação entre sites
O segundo cenário, descrito na figura 2, é muito parecido com o primeiro cenário. De fato, o segundo cenário é a junção de dois cenários 1. No primeiro cenário foi apontado onde se deve controlar a prioridade dos fluxos saintes da LAN para a WAN. Podemos imaginar o Cenário 1 como o acesso a Internet.
Figura 2: Cenário 2 - Interligação entre sites
O cenário 2 pode ser imaginado como uma ligação entre dois sites de uma mesma empresa. Neste caso, iremos controlar a prioridade dos fluxos em ambos os sentidos. Na interface de saída da interface WAN do roteador do SITE 1 controlamos a prioridade dos fluxos destinados ao SITE 2, e na interface de saída da interface WAN do roteador do SITE 2 controlamos a prioridade dos fluxos destinados ao SITE 1.
3.1.3. Cenário 3 – Rede local
O terceiro cenário, ilustrado na figura 3, possui uma característica diferente dos dois cenários apresentados anteriormente. Nos cenários 1 e 2 são apontados os pontos onde as políticas de priorização de tráfego devem ser habilitadas em um roteador. Nestes cenários a priorização é sempre baseada no nível 3, ou seja, na marcação de pacotes IP.
No cenário 3 (figura 3) não há roteador. Há apenas switches. Logo, a priorização de tráfego deve ser feita em nível 2.
Figura 3: Cenário 3 - Rede local
Entretanto, a premissa de identificar pontos de gargalo, onde um equipamento de rede recebe mais banda por uma interface (ou um conjunto de interfaces) do que consegue transmitir por outra interface continua valendo.
Seguindo esta premissa, é possível identificar três pontos de gargalo no cenário 3. Note que se cada um dos computadores gerarem 100 Mbps destinados a algum elemento conectado diretamente ao switchcore, os pontos indicados as interfaces de uplink dos switches ficarão engargaladas. Logo, é possível identificar que tais pontos são efetivos para a aplicação de políticas de priorização de tráfego.
4. Suportando tráfego de voz - Nível 3
As rotas de nível 3 por onde a voz trafega devem ser identificadas. Os pontos onde as políticas de priorização de voz são efetivas (gargalos) devem ser identificados, e as recomendações descritas nos subtópicos desta seção devem ser averiguadas.
4.1. Marcação de pacotes de voz e desmarcação de pacotes não legítimos
Todos os pacotes referentes aos fluxos de voz devem ser marcados;
Recomenda-se o uso de DSCP EF;
Os pacotes de voz podem ser caracterizados pelos endereços IP dos equipamentos envolvidos e pelas portas de transporte utilizadas pelos aplicações VoIP:
Porta UDP 5060 – SIP
Porta UDP 10000 a 20000 – RTP (padrão InstantVoice ®)
IP dos Media Gateways (E1, FXO e FXS)
IP das estações que com softphone VoIP
IP dos softswitches
Pacotes não associados aos fluxos de voz marcados como pacotes de voz (DSCP EF) devem ser desmarcados (pacotes não legítimos);
A marcação deve ser realizada em qualquer equipamento que esteja localizado anteriormente ao primeiro roteador que opera alguma política de priorização de fluxos de voz, incluindo o este próprio roteador (desde que a marcação seja realizada anteriormente ao mecanismo de priorização);
A desmarcação de pacotes não legítimos deve ser realizada em qualquer equipamento que esteja localizado anteriormente ao primeiro roteador que opera alguma política de priorização de fluxos de voz, incluindo o este próprio roteador (desde que a marcação seja realizada anteriormente ao mecanismo de priorização).
4.2. Política de gerência de fila
Os fluxos referentes aos pacotes de voz devem ser gerenciados por uma fila que garanta a banda que se deseja reservar para voz (olhar seção 2.1);
Recomenda-se uma política de fila que sirva os pacotes de voz com prioridade máxima até a exaustão (atendendo o limite de banda reservado). Este política é comumente conhecida como “Priority Queue” (ou simplesmente PQ) e é oferecida pela maioria dos equipamentos de rede que suportam priorização de tráfego IP;
Recomenda-se que os fluxos menos prioritários, que não são tratados pela PQ, sejam tratados por uma política da de filas do tipo “Fair Queue”, de modo que aplicações interativas de menor consumo de banda (como SSH, TELNET, HTTP, entre outras) não sejam atrapalhadas por aplicações não interativas de maior consumo de banda (download FTP, download HTTP, entre outras). O uso de Fair Queue também diminui a probabilidade de que a voz seja degradada caso a banda reservada pela PQ seja extravasada (o tráfego que extravasar da PQ deve ser direcionado para a Fair Queue );
Alguns fabricantes alertam que a reserva de mais de mais de 33% da banda de um enlace para PQ pode causar inanição aos fluxos de menor prioridade;
Deve-se verificar o tamanho do buffer das interfaces dos equipamentos que estão priorizando os fluxos de voz. Os equipamentos costumam utilizar um buffer de saída do tipo FIFO (First In First Out), que quando configurado com valores elevados, podem diminuir a eficiência do mecanismo de priorização e acrescentar muito atraso na rede.
É importante alertar que é comum que, após a habilitação de mecanismos de priorização, os buffers de saída sejam configurados automaticamente para valores padrões que usualmente são demasiadamente altos. Estes buffers precisam ser ajustados levando-se em conta as necessidades de atraso exigidas pela voz (olhar seção 2.3).
4.3. Fragmentação para enlaces de baixa velocidade
Em enlaces com velocidades inferiores a 1024 kbps, torna-se necessária a utilização de técnicas como LFI (Link Fragmentation and Interleaving). O tempo de serialização de um pacote em uma interface é inversamente proporcional à velocidade do link desta interface; um pacote de voz pode sofrer um atraso inaceitável aguardando o término da transmissão de um pacote de dados em um link de baixa velocidade. O LFI faz com que um quadro sendo enviado seja fragmentado em tamanhos menores, permitindo a inserção de pacotes prioritários entre eles.
A tabela 2 apresenta o tamanho de fragmentos recomendados para enlaces de baixa velocidade.
Tabela 2: Fragmentação em enlaces de baixa velocidade
4.4. Atenção ao uso de mecanismos de tratamento de congestionamento
Não deve-se utilizar de algoritmos para tratar congestionamentos nas filas associadas aos fluxos de voz, como RED (Random Early Detection) ou WRED (Weighted Random Early Detection). Estes algoritmos causam descartes de pacotes que afetarão a qualidade da voz.
4.5. Coerência com o provedor de acesso
É importante ter em mente que o provedor de acesso também deve priorizar o tráfego de voz, e que deve existir uma coerência entre a configuração de priorização de tráfego adotada internamente e a política de priorização adotada pelo provedor.
O provedor deve ser informado como os pacotes de voz estão sendo marcados para que as regras de priorização sejam mapeadas para dentro da rede do provedor.
5. Suportando tráfego de voz – Nível 2 (Rede local)
Uma vertente para suporte de voz em rede local é a segmentação em nível 2 baseada em VLAN com uso de priorização segundo o padrão 802.1Q/p. Entretanto, este tipo de infra-estrutura acrescenta muita complexidade à solução.
A priorização segundo o padrão 802.1Q/p deve ser configurada pela aplicação, e a placa de rede dos equipamentos VoIP (estações de trabalho que operam SoftPhone, Telefones IP, Media Gateways, Softswitches, entre outros), assim como seus respectivos sistemas operacionais, devem suportar o 802.1Q/p. Também há a necessidade de configuração individual de cada um destes equipamentos.
A segmentação por VLAN exige ainda que as portas dos switches onde estes equipamentos se interligam também sejam identificadas e configuradas para segmentação da VLAN.
O roteamento de nível 3, para encaminhamento entre VLANs também se torna necessário, adicionando assim, mais custo para solução, já que normalmente há a necessidade de investimento em switches de nível 3 de alta performance.
Outra vertente, que em alguns casos também exige investimentos, mas que por outro lado não aumenta a complexidade da rede, é a aproximação dos equipamentos VoIP do core da rede. Esta vertente segue as seguintes premissas:
Os pontos de gargalo de nível 2 (como ilustrado na seção 2.1.3) devem ser minimizados nas rotas de voz;
Cada equipamento VoIP (estações de trabalho que operam SoftPhone, Telefones IP, Media Gateways, Softswitches, entre outros) deve ter uma interface Full Duplex de ao menos 100 Mbps dedicada até o switch de acesso. O cascateamento de uma estação de trabalho a um Telefone IP com switch interno é permitido;
Equipamentos que concentram muitas chamadas de voz, como Media Gateways e Softswitches (E1 ou FXS) devem estar ligados diretamente ao core da rede;
Estações de trabalho que utilizam voz como aplicação de missão crítica (estações de operadores de um Call Center) devem possuir um cascateamento máximo de 1 nível (um switch) até o core da rede, e devem estar conectadas a switches dedicados;
O cascateamento entre os switches deve ser realizados através de enlaces de maior velocidade como, por exemplo, Gibabit Ethernet ou FastEthernet Channel (junção de grupos de interfaces FastEthernet operando em paralelo).
Figura 4: Infra-estrutura de rede local
A figura 4 ilustra uma infra-estrutura de rede local que segue as premissas descritas acima. Os switches estão classificados em três grupos: Core, distribuição e acesso. Os switches Core estão conectados a alta velocidade e abrigam os elementos que concentram muitas chamadas de voz, como os Media Gateways e o SoftSwitch/DAC, assim como, os switches dedicados às estações dos operadores de CallCenter que operam SoftPhones. Os switches de distribuição interligam os switches de acesso em alta velocidade. Os switches de acesso por sua vez, oferecem portas FastEthernet dedicadas a cada um dos Telefones IP e as estações de trabalho que operam SoftPhones.
6. Balanceamento de Carga / Load Balance
Para a Voz sobre IP (VoIP) e/ou outros fluxos que exigem a entrega em sequência não é recomendado a utilização de um balanceamento de carga, visto que no cabeçalho do pacote é definido o endereçamento IP da origem e do destino.
Caso exista um balanceamento, o tráfego pode tomar caminhos diferentes, o que poderia introduzir a reordenação dos pacotes causando paralisação total ou parcial de uma ligação.
Recomenda-se nesses casos que se crie uma regra onde os pacotes de telefonia trafegam somente em um dos links, assim os caminhos de ida e de volta serão sempre os mesmos.
7. Controles de Segurança
7.1. VLAN
A utilização de VLAN é recomendada por permitir a segmentação lógica da rede criando domínios de colisão e de broadcast distintos entre o tráfego de dados e o tráfego de voz. Dessa forma, previne-se que problemas em um segmento de rede interfira no outro e vice-versa.
Ataques de negação de serviço, sniffer (escuta da rede), tentativas de escuta de ligações indevidamente ou até mesmo instabilidades na rede de dados provocados pela atuação de pragas virtuais como vírus e worms terão seus efeitos minimizados com a segregação das redes promovida com o uso de VLAN.
7.2. 802.1x
O IEEE 802.1X é um método de controle de acesso de porta a rede local. Um dispositivo conectado a uma porta ativada com 802.1X não pode enviar ou receber pacotes na rede até que sua identidade possa ser verificada (por meio de um nome de usuário e senha, por exemplo).
O 802.1 X utiliza o protocolo de autenticação extensível (EAP) para transferir as credenciais de um dispositivo para um servidor de autenticação (normalmente RADIUS) usando um dispositivo de acesso de rede intermediário obrigatório, na maioria dos casos, um switch. O dispositivo de acesso à rede media toda a comunicação entre o dispositivo do usuário final e o servidor de autenticação para que a rede permaneça segura. Se o servidor de autenticação determinar que as credenciais são válidas, o dispositivo do usuário final é autorizado a acessar os recursos localizados no lado protegido da rede.
Acessos não autorizados na rede, sniffer (escuta da rede) e tentativas de escuta de ligações indevidamente terão seus efeitos minimizados com a ativação do uso do protocolo EAP na sua rede local. Normalmente para ambiente VoIP, a implementação é realizada utilizando os protocolos EAP-MD5 ou EAP-TLS. Porém, antes de tomar a decisão de qual utilizar, é recomendado que sejam verificados os protocolos suportados pelos dispositivos do usuário final, por exemplo: telefone IP.
7.3. Firewall, IDS e IPS
A utilização de equipamentos como firewalls, IDS (Intrusion Detection System) e IPS (Intrusion Prevention System) visam proteger segmentos de rede contra ameaças externas. Esses equipamentos são estrategicamente inseridos na infra-estrutura de rede de modo que todo tráfego entre os segmentos de redes que se deseja proteger seja inspecionado.
O firewall é o elemento de fronteira entre a Internet ou zonas de rede não confiáveis e redes locais ou zonas confiáveis. O firewall é um dispositivo de segurança de rede que monitora o tráfego de entrada e saída da rede e decide se permite ou bloqueia o tráfego específico com base em um conjunto definido de regras de segurança. O processamento do tráfego pelo firewall é realizado através de uma técnica denominada filtro de pacotes. Esse processo consiste em analisar informações contidas no cabeçalho de cada pacote que atravessa o firewall como endereços IP, portas e tipo de protocolos a fim de identificar os pacotes legítimos.
7.3.1 Recursos e configuração do Firewall
O firewall controla o tráfego redirecionando a sinalização SIP e os fluxos de mídia de áudio para os destinos definidos. Nesta solução, o firewall está controlando as comunicações para permitir que o tráfego de tronco SIP de operadoras seja direcionado para o PBX IP.
Encaminhamento de porta (Port Forwarding)
Uma das funções principais de um firewall é negar TODO o tráfego não solicitado de redes não confiáveis.
Em vez de permitir que qualquer pacote seja redirecionado através do firewall com Port Forwarding, o firewall geralmente tem uma configuração que definirá um (s) endereço (s) IP de origem, em que o pacote UDP / TCP dentro do endereço IP de origem deve corresponder ao valor definido. Basicamente, a criação de uma Lista de Controle de Acesso (ACL), que é útil na aplicação de tronco SIP ponto a ponto, já que o endereço IP de um ponto pode ser aceito e redirecionado para um destino definido. A limitação é o uso de Domínios, onde o endereço IP de origem pode ser dinâmico.
O protocolo SIP normalmente opera na porta UDP / TCP 5060. As mensagens de sinalização SIP são enviadas de um par e redirecionadas para outro par nesta porta UDP / TCP. Portanto, configure um Encaminhamento de Porta do Protocolo SIP de um ponto a outro para permitir o envio de mensagens SIP. Os pacotes RTP de mídia de áudio podem operar em qualquer porta UDP, mas normalmente de 10.000 a 20.000. Essa é uma quantidade enorme de portas para o Port Forward e pode limitar o uso dessas portas por outros aplicativos. Esta nem sempre é uma solução viável e não muito segura, pois dezenas de milhares de portas estão abertas no firewall e direcionadas ao IP-PBX.
Além disso, a falsificação do endereço IP de origem é a maneira mais comum e fácil de contornar as listas de controle de acesso em firewalls. É fácil configurar a falsificação de endereços IP em muitos sistemas operacionais de computador. Esteja ciente de que o ACL não deve ser o único recurso de segurança em operação. Lembre-se de que o protocolo SIP é um protocolo de camada de aplicativo do modelo OSI e o endereçamento é independente dos endereços IP da camada de transporte. A falsificação do endereço IP terá pouco ou nenhum efeito no endereçamento SIP do VoIP.
7.3.2 Sistema de Detecção de intrusão (IDS)
Um sistema de detecção de intrusão (IDS) em um IP-PBX é um aplicativo que monitora a comunicação com o IP-PBX em busca de atividades maliciosas ou violações de políticas. Qualquer atividade ou violação detectada é normalmente notificada ao administrador do IP-PBX. As políticas de IDS típicas incluem tentativas de registro, tentativas de falha de senha, detecção de assinatura de pacote SIP (padrões conhecidos) e detecção de anomalia (desvios de bom tráfego). O Intrusion Prevention System (IPS), geralmente associado ao IDS, atua como o sistema de resposta automatizado ao negar proativamente a atividade maliciosa após a detecção. Isso inclui o encerramento de conexões e a inclusão de partes ofensivas na lista negra.
7.4. Sinalização SIP
O mecanismo de autenticação da sinalização SIP é usado para fornecer segurança ao processo de requisições de mensagens envolvendo o registro e o início de sessões (métodos REGISTER e INVITE). Na figura 5 é ilustrado o fluxo de mensagens envolvidas no processo de registro SIP com autenticação.
Figura 5: Processo de autenticação SIP
8. Conclusão
As recomendações apresentadas neste material visam nortear os princípios básicos de infraestrutura para a garantia da qualidade de voz e vídeo trafegando sobre o protocolo IP.
Este documento foi desenvolvido a partir de nossa experiência em casos reais de uso, e está em constante aprimoramento à medida que novos cenários demandem sua atualização.