«

»

abr 14 2008

Unified Communications – Parte II

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:

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

    0
    0

    5 comentários

    Pular para o formulário de comentário

    1. Rodrigo Farias

      Opa, desculpa a demora, é porque eu não tinha lido o primeiro ainda…

      Aconselho a TODOS (sem excessão) lerem os dois posts e o que virá..

      Tirei algumas dúvidas que eu tinha, muito válido.

      Estou aguardando a última parte (assim que vc tiver tempo é claro) 🙂

      Abraço

      0

      0
    2. Fabio A de Amorim

      Muita bacana os dois artigos Marco! Esperamos o terceiro….

      Parabéns! 😉

      Abraços,
      Fábio A. de Amorim

      0

      0
    3. Rafael Carvalho

      Muito legal.
      Vale lembrar que a Microsoft está entrando nesse mercado de sola com solução semelhante a essa da CISCO.
      Vai ser uma concorrência legal.

      0

      0
    4. vstrabello

      Sobre mobilidade, um recurso interessente no ambiente de IPT da Cisco disponível com o Cisco CallManager, é o Extension Mobility. Com ele, é possível “levar” o seu ramal em qualquer site que tenha IPT da Cisco. Como funciona? No Cisco CallManager tem o serviço LDAP, chamado DC Directory que contém as bases LDAP para cada usuário desta função no Cisco CallManager. Cada usuário é associado á um Device Profile, Ramal (Conhecido como Directory Number) e por aí vai. Este serviço está disponível nos Telefones IP através do botão Services, que oferece um menu de aplicações web/XML disponíveis, que entre elas, está o serviço Extension Mobility. Selecionando esta opção do menu, irá aparecer a tela pedindo o usuário e o PIN para “puxar” o seu ramal para aquele telefone. Legal, não? 😉 Podemos também integrar o Cisco CallManager com o Active Directory para isso, facilitando a nossa vida de inserir usuários e senhas no Cisco CallManager usando uma base de dados já existente.

      Segue um link explicando como funciona a integração com LDAP, no caso com o Active Directory:

      Cisco Unified Communications SRND Based on Cisco Unified Communications Manager 5.x – LDAP Directory Integration [Cisco Unified Communications Manager (CallManager)] – Cisco Systems:
      http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/5x/50drctry.html

      Abraços!

      0

      0
    5. ferrugem

      Realmente essa conversão não é nada barato Marco. Se não me engano, aqui na empresa, quando passamos pelo processo de migração da plataforma Analógica – VOIP, o custo foi na escala dos 6 zeros… 😀

      Na parte de voz, não utilizamos equipamentos Cisco, a estrutura é toda AVAYA, mas o conceito acredito ser o mesmo.

      Já os nossos switchs, incluindo os PoE, e Routerssão todos Cisco.

      Desde que cheguei na empresa muitas coisas aconteceram, e me sinto feliz por ter participado de toda essa evolução. Hoje temos toda nossa Infra-Estrtura suportada por equipamentos de primeira linha, fato este que não se verificava a pouco tempo atrás. 😀

      Muito bom este tema por ti abordado, e fico no aguardo da 3.ª parte!!! Parabéns mais uma vez.. Tenho muito o que aprender por aqui ainda!!! 😉

      Abraços a todos da comunidade!!!

      0

      0

    Deixe uma resposta