Voz e comunicações unificadas : Cisco Unified Communications Manager (CallManager)

Estabelecendo troncos intercluster com três ou mais CallManagers de Cisco

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Um link intercluster é uma conexão H.323 que permite que dois clusters do CallManager da Cisco roteiem chamadas entre si em uma nuvem IP. Quando se conectam dois ou mais clusters do CallManager multisservidor 3.1.x ou 3.2.x, uma configuração de tronco incorreta pode causar problemas no roteamento de chamadas entre os dois clusters. A Cisco aprimorou e simplificou a configuração na versão 3.3.x do CallManager.

  • Cluster-a

    • CM-A1

    • CM-A2

    • CM-A3

    • IPPhone-A1 (registrado com CM-A1)

    • IPPhone-A2 (registrado com CM-A2)

    • IPPhone-A3 (registrado com CM-A3)

  • Cluster-b

    • CM-B1

    • CM-B2

    • IPPhone-B1 (registrado com CM-B1)

    • IPPhone-B2 (registrado com CM-B2)

  • Tronco inter-grânulo

    • CM-A1 �-� CM-B1

intercluster_1.gif

Pré-requisitos

Requisitos

Os leitores deste documento devem compreender como administrar redes CallManager.

Componentes Utilizados

A informação neste documento é baseada na versão do CallManager 3.1x, 3.2x, e 3.3x.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Problema

IPPhone-A2 e IPPhone-A3 não podem executar nenhuns atendimentos sobre o tronco inter-grânulo.

Atendimentos de IPPhone IPPhone-B1 IPPhone-B2
IPPhone-A1 O A1 pode chamar o B1 O A1 pode chamar o B2
IPPhone-A2 O A2 não pode chamar o B1 O A2 não pode chamar o B2
IPPhone-A3 O A3 não pode chamar o B1 O A3 não pode chamar o B2

Isto é porque, quando IPPhone-A2 tenta estabelecer um atendimento, o atendimento é iniciado no CM-A2 e nos pontos ao CM-B1. Porque somente um tronco inter-grânulo foi configurado (entre o CM-A1 e o CM-B1), o CM-B1 não está ciente da existência do CM-A2 como um valor-limite de H.323. Em consequência, o atendimento é rejeitado pelo CM-B1 e falha.

intercluster_2.gif

soluções 3.1.x ou 3.2.x

Há três maneiras de resolver a edição. Estas soluções são explicadas nas próximas seções. Além, os profissionais - e - contra estão listados para cada solução.

Solução 1 — A criação de um Pseudo--porteiro no Cluster-a e no Cluster-b, então “permite chamadas anônima”

A primeira solução envolve uma configuração de gatekeeper que permita dispositivos anônimo.

Esta solução permite que cada um dos valores-limite do inter-conjunto receba uma chamada recebida de um valor-limite desconhecido de H.323. Assim, o atendimento do CM-A2 pode ser aceitado e estabelecido.

Quando você configura o porteiro, termine os campos necessários conforme o Guia de Administração.

Nota: Pague a atenção especial aos campos das chamadas anônima e do protocolo de dispositivo reservar, que são marcados neste screen shot:

intercluster_3.gif

Pros

  • Configuração simples — Nenhuma alteração da configuração de roteamento de chamada é exigida.

  • Escalabilidade — Configuração do dispositivo único.

  • Escalabilidade — Você precisa somente de configurar um conjunto novo para conectá-lo à rede.

Cons

  • Redundância — Nenhuma redundância de saída, no caso da falha explicitamente de servidores configurados (neste exemplo, CM-A1 ou CM-B1). Rota única ao conjunto remoto.

  • Elegância — Não “limpe” a solução, porque um porteiro “falsificado” é criado.

  • cuidado Cuidado: Permite valores-limite desconhecidos do tronco inter-grânulo (exemplo: um Cluster do CallManager daCisco desconhecido) para estabelecer atendimentos ao conjunto.

Solução 2 — Configuração explícita de um tronco inter-grânulo para cada CallManager da Cisco remoto

Esta solução exige-o configurar os troncos de cluster interno explícitos em cada Cluster do CallManager daCisco, cada qual apontam a todos os servidores do CallManager da Cisco remotos. Não é necessário alterar o roteamento de chamada; deve permanecer o mesmo que com um único tronco inter-grânulo.

intercluster_4.gif

Esta solução permite que cada conjunto esteja “ciente” dos servidores remotos. Assim, o atendimento do CM-A2 é aceitado e estabelecido.

Pros

  • Configuração simples — Nenhuma alteração da configuração de roteamento de chamada é exigida.

Cons

  • Redundância — Nenhuma redundância de saída, no caso da falha dos servidores primários (neste exemplo, CM-A1 ou CM-B1).

  • Escalabilidade — Uma malha parcialmente cheia é exigida.

  • Escalabilidade — Você deve reconfigurar todos os conjuntos quando um conjunto novo é adicionado à rede.

Solução 3 — Configuração explícita de um tronco inter-grânulo para cada CallManager da Cisco remoto incluído nas Rota-lista

Esta solução exige-o configurar os troncos de cluster interno explícitos em cada Cluster do CallManager daCisco, cada qual apontam a todos os servidores do CallManager da Cisco remotos. É necessário alterar o roteamento de chamada: crie uma lista da rota que inclua um grupo de rotas que contenha todos os troncos inter-grânulo configurados, por ordem da preferência. Esta lista da rota deve ser o destino da rota padrão que é responsável para o roteamento de chamada entre clusters.

intercluster_4.gif

Esta solução permite que cada conjunto esteja “ciente” dos servidores remotos. Assim, o atendimento do CM-A2 é aceitado e estabelecido. Igualmente permite que os atendimentos estejam estabelecidos em troncos de backup, caso que o tronco principal ou o server vão para baixo.

Pros

  • Redundância — Redundância de saída, no caso da falha dos servidores primários (neste exemplo, CM-A1 ou CM-B1).

Cons

  • Complexidade — A alteração da configuração de roteamento de chamada é exigida.

  • Escalabilidade — Uma malha parcialmente cheia é exigida.

  • Escalabilidade — Você deve reconfigurar todos os conjuntos quando um conjunto novo é adicionado à rede.

realce 3.3.x e configuração

O CallManager da Cisco 3.3.x introduziu uma interface de configuração nova que facilitasse configurar troncos inter-grânulo redundantes, quando você deve usar o protocolo do tronco inter-grânulo. Em umas versões do CallManager mais adiantadas, os gateways múltiplos e uma configuração complexa foram exigidos, adicionar o mesmo nível da Redundância.

Configuração de um único tronco inter-grânulo com valores-limite múltiplos IP

A configuração do tronco inter-grânulo do CallManager da Cisco 3.3.x exige o administrador criar um gateway único em cada conjunto com os endereços IP de Um ou Mais Servidores Cisco ICM NT de até três servidores do CallManager remotos. Este gateway único estará disponível a todos os servidores do CallManager em seu conjunto respectivo. Para ajustar a prioridade, configurar o CallManager remoto na ordem que você prefere.

intercluster_5.gif

Para obter informações adicionais sobre da configuração dos caminhões no CallManager 3.3x, refira a configuração de tronco.

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 19200