quinta-feira, 3 de maio de 2012

CUBE - Parte 1 (Conceitos)

Configuração de CUBE é um dos temas mais complicados da prova, na minha opinião. Isso porque quase não implementamos no dia-a-dia, e também porque esse assunto estava lá no finalzinho do livro do CVOICE... hehehe! Aí passamos meio batido. Nesse post vou tentar esclarecer um pouquinho sobre os conceitos de CUBE e Via Zones.

Vamos supor que temos duas empresas distintas, uma com um CUCM e outra com um CME. E elas querem fazer a integração da telefonia. Bom, isso seria bem tranquilo, não? Poderiamos criar um trunk H.323 e apontar direto as rotas de um sistema para o outro. Só que a vida não é assim tão fácil... nos passaram um requisito de que eles não querem que seja trocada sinalização diretamente entre os dois dispositivos... O que é bem aceitável, pois poderiamos ter problemas de segurança, roteamento, etc. Então precisamos de um cara que fique no meio do caminho, interceptando a comunicação entre as duas pontas, e fazendo com que o CUCM e CME não se falem diretamente.  É justamete aí que entra o CUBE (Cisco Unified Border Element). Esse produto no mercado é também conhecido como SBC (Session Border Controller). Logo, o CUBE é o SBC da Cisco.

O CUBE essencialmente é um Gatekeeper... e nele vamos configurar 3 zones: ZoneCUCM, ZoneCME e ZoneCUBE. Em termos de configuração, o CUBE é o mesmo device físico que o Gatekeeper, porém é mais fácil pensarmos nele como se fosse uma entidade separada.

Bom, vamos ao nosso Call Setup. Para o exemplo, vamos considerar que o range de ramal do CUCM é 1XXX e o do CME é 2XXX.
Quando o CUCM for fazer uma chamada para o CME, ele enviará um ARQ (Admission Request) para o Gatekeeper, que verificará na sua lista para qual zone irá rotear a chamada. Ele vê que as chamadas para 2XXX devem ser roteadas para a ZoneCME, mas ao invés de enviar a chamada para essa Zone, ele manda ela para ZoneCUBE (veremos o porquê nas configurações). Portanto, quando o Gatekeeper responde o ACF (Admission Confirm) para o CUCM, ele manda o IP do CUBE, e não do CME! Dessa forma, a sinalização H225 é fechada entre o CUCM e o CUBE (que é o Gatekeeper). Essa é a sacada, porque o CUCM nunca recebe o IP do CME para trocar mídia e sinalização. Se pensarmos que o CME está em uma outra empresa, com outro endereçamento, isso faz todo o sentido do mundo, não?
Continuando, quando o CUCM faz o Call Setup com o CUBE, o CUBE manda um outro ARQ para o Gatekeeper (sim, o CUBE e o GK são o mesmo roteador. Na prática, ele manda a mensagem para ele mesmo. Mas lembre-se que devemos sempre encarar o CUBE e o GK como duas entidades separadas). E o Gatekeeper agora responde um ACF, e o CUBE fecha o H225 com o CUCM. Nesse ponto da chamada, a perna CUCM - CUBE já está ok, agora ele vai estabelecer a outra perna (CUBE - CME).
O CUBE agora manda um novo ACF para o Gatekeeper solicitando uma chamada para o CME. O Gatekeeper então responde um ACF para o CUBE, que faz o setup do H225 com o CME. Ao receber esse setup, o CME manda também um ARQ para o GK perguntando se ele pode aceitar a chamada, e o GK responde um ACF autorizando o call setup.
Quando a chamada é estabelecida, o audio pode trafegar de duas formas entre as duas pontas. Uma é o media flow through (default), que separa o RTP em 2 (CUCM-CUBE e CUBE-CME) e o media flow around, que faz um bypass no CUBE e fecha direto entre as duas pontas.
A topologia abaixo mostra tudo o que eu acabei de escrever. Ela foi retirada de uma apresentação do Mark Snow para o Internetwork Expert.



Ok, ficou confuso! Mas tudo isso foi para falar que quando usamos o CUBE, o Gatekeeper intercepta a chamada através de uma zone especial chamada de via zone. E as duas pontas nunca se falam diretamente. Veremos que em uma chamada assim, quando damos um show gatekeeper calls, o output nos mostras duas chamadas ao invés de uma.

Dada essa (tentativa de) explicação, no próximo post vou escrever o que interessa mais para nós: as configurações.

Nenhum comentário:

Postar um comentário