Vamos dar andamento ao tema abordado anteriormente pela parte I deste post. Nele, demos uma rápida olhada na arquitetura e operação de uma rede VoIP, onde os PABX tradicionais (TDM) são mantidos e interconectados à uma rede de dados por intermédio dos “Voice Gateways” (VGW). Vamos agora ver como seria uma arquitetura um pouco mais complexa, chamada de IP Telephony (IPT).

Na arquitetura IPT, o PABX tradicional é completamente substituído por um “PABX IP” (também conhecido como “Soft Switch”, quando inserido em um contexto de operadora de telefonia). Uma vez que o PABX tradicional sai de cena, algumas mudanças importantes devem ocorrer na rede:

1. Os telefones digitais que se conectavam ao PABX devem ser obrigatoriamente substituídos por telefones IP;
2. Os telefones analógicos PODEM ser substituídos por telefones IP, mas existe ainda a opção de mantê-los, conectando-os à um elemento especial, como um ATA (Analog Telephone Adapter), um Gateway Analógico para IP, como o Cisco VG224 ou VG248 (na essência, são equipamentos com uma grande densidade de portas telefônicas analógicas FXS de um lado, e uma porta Ethernet (IP), do outro);
3. Os switches LAN tradicionais devem ser substituídos por switches com suporte à PoE (Power over Ethernet), OU os novos telefones IP precisarão de fontes externas de alimentação (nada prático). A opção por switches PoE é mais interessante, especialmente se tomadas livres não são facilmente encontradas nas baias dos usuários, por exemplo;
4. A rede LAN (e WAN) precisa oferecer suporte à qualidade de serviço. Na verdade, na arquitetura VoIP, a WAN já precisaria oferecer esta funcionalidade. No modo IPT, a LAN - os switches, no caso - também precisa ter este suporte;
5. O cabeamento precisa estar dentro dos requisitos mínimos para o funcionamento de uma rede IPT. Ou seja, o cabeamento deve ser, no mínimo, categoria 5e;
6. A largura de banda da rede como um todo precisa ser revista. Dentro da LAN, cada chamada consome em torno de 80 Kbps (utilizando o codec G.711, que oferece melhor qualidade, porém, sem muita compressão). Na WAN, cada chamada consome entre 20 a 40 Kbps, dependendo do CODEC utilizado. Normalmente, como a banda da LAN é menos custosa (e mais abundante), utiliza-se um CODEC com menor taxa de compressão neste tipo de rede, e um CODEC que ofereça uma maior taxa de compressão em links WAN (geralmente mais caros). Ganha-se banda, mas perde-se um pouco de qualidade e aumenta-se a necessidade de CPU no Voice Gateway, já que os CODECs que oferecem uma maior taxa de compressão utilizam algoritmos mais complexos.

Eis a lista com alguns CODECs existentes, e as respectivas largura-de-banda consumidas, por chamada (desconsiderando o overhead):

GIPS Family - 13.3 Kbps and up

GSM - 13 Kbps (full rate), 20ms frame size

iLBC - 15Kbps,20ms frame size: 13.3 Kbps, 30ms frame size

ITU G.711 - 64 Kbps, sample-based Also known as alaw/ulaw

ITU G.722 - 48/56/64 Kbps ADPCM 7Khz audio bandwidth

ITU G.722.1 - 24/32 Kbps 7Khz audio bandwidth (based on Polycom’s SIREN codec)

ITU G.722.1C - 32 Kbps, a Polycom extension, 14Khz audio bandwidth

ITU G.722.2 - 6.6Kbps to 23.85Kbps. Also known as AMR-WB. CELP 7Khz audio bandwidth

ITU G.723.1 - 5.3/6.3 Kbps, 30ms frame size

ITU G.726 - 16/24/32/40 Kbps

ITU G.728 - 16 Kbps

ITU G.729 - 8 Kbps, 10ms frame size

Speex - 2.15 to 44.2 Kbps

LPC10 - 2.5 Kbps

DoD CELP - 4.8 Kbps

Como vocês podem observar, não são poucas (ou baratas) as mudanças necessárias para acomodar um ambiente IPT! Mas vamos prosseguir… abaixo, o diagrama de como nossa rede ficaria, em uma arquitetura IPT:

Com a eliminação do PABX TDM, entra em cena o PABX IP, no caso da Cisco, chamado de Call Manager [2] (recentemente o nome foi alterado para “Cisco Unified Communications Manager” - CUCM). O Call Manager (CM) é coração de nossa rede IPT, e é responsável por realizar todas as funções do antigo PABX, e muito mais. Ele realiza o registro dos telefones da rede IPT [5], cuida da sinalização das chamadas, faz o roteamento das chamadas, controla música de espera, etc! Além disso, ele pode gerenciar o uso de banda em uma rede IPT, controlar os gateways de voz [4](se o protocolo de comunicação utilizado for o MGCP), centralizar aplicações, integrar com o sistema de correio de voz (como o Unity Voice Mail [3]), integrar com o sistema de correio eletrônico (como o MS Exchange ou o Lotus Notes), dentre outras funções. Bom, e qual a “cara” do CM? Basicamente, o CM é apenas um software…! Isso mesmo! Um SW que é instalado em um PC. Ou seja, quando você olha para o CM, está olhando para um… PC (turbinado, mas ainda… um PC!).

E o que mais temos em uma rede IPT? Temos os switches PoE [1], já mencionados, que são responsáveis por alimentar os telefones IP com energia elétrica. Isso dispensa o uso de fontes de alimentação externas para os telefones. Temos o Unity, um sistema de correio de voz [3], que também é um software, instalado em um PC. Este sistema integra-se com o CM e é responsável pela gerência das mensagens de voz dos usuários.Notem que a rede diagramada possui apenas UM Call Manager, e UM Unity VM…! Ambos centralizados no site A. O site B não possui estes elementos.

E como os telefones no site B, então, funcionam? Eles registram-se remotamente no site A! Esta é uma das grandes vantagens de uma rede IPT: Mobilidade! Você não precisa ter um PABX IP local. Basta que seu telefone IP tenha acesso ao Call Manager remoto e pronto! No exemplo, os telefones do site B enviam solicitações de registro ao CM no site A via rede WAN. E se a rede WAN cair? Neste caso, o gateway do site B encontra-se habilitado com um recurso conhecido como SRST (Survivable Remote Site Telephony). Esta funcionalidade, resumidamente, ativa a função de CM em um roteador Cisco (no caso , o VGW), o qual recebe uma cópia parcial da base de dados do CM e é capaz de manter os telefones no site B funcionando mesmo no caso de uma interrupção da comunicação com o CM no site A. Ou seja, o VGW do site B passa a responder aos telefones IP deste site como se fosse o próprio Call Manager! Obviamente, esta funcionalidade custa alguns $$$ a mais .

E como integrar equipamentos legados, como aparelhos de FAX ou MODEMs, à esta rede ultra-moderna? Existem algumas soluções: Uma delas involve o uso de gateways analógicos-IP, como o ATA, por exemplo. Outra se resume em instalar um módulo de telefonia analógica (FXS) no Voice Gateway, e conectar os aparelhos de FAX nestas portas.

Bom, basicamente… é isso! Na última parte deste artigo vou discorrer sobre as comunicações unificadas, de fato. Ou seja, a integração de uma rede IPT com outros meios de comunicação, como e-mails, vídeo, etc, e o que os grandes players do mercado estão aprontando em relação à isso! E tem MUITA coisa acontecendo !

Abraços pessoal! E uma excelente semana para todos nós

Marco.

---

Leia também:

• Unified Communications - Parte I
• Unified Communications… de novo!
• Webcast Cisco: Online Channel Event: Unified Communications Update
• VoIP vs Telefonia IP
• [P&R] Hub? Switch? Hub/Switch?: Afinal, qual a diferença entre cada um destes elementos?
• Ceará introduz o BoIP - Bode over IP ;-)
• Redes Metro-Ethernet
• [P&R] Quais as diferenças entre switches L2 e L3?
• Resumo (Tutorial) sobre ISDN
• Mercado: VAGAS
• QoS (Qualidade de Serviço) - parte I/IV
• Video over IP, herói ou vilão?
• Guia rápido das profissões relacionadas à Redes
• Lab de IP Telephony no Dynamips
• CiscoWorks LMS - Sistema de Gerenciamento

Este post foi postado Monday, 14 de April de 2008 às 1:58 am e está em Exames CCXP, Artigos. Você pode verificar qualquer resposta a este post através do feed RSS 2.0. Você pode deixar uma resposta, ou fazer um trackback de seu próprio site.