Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Configurar los troncos entre clústers con tres o más Ciscos CallManageres

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Un link entre clústers es una conexión H.323 que permite que dos clústers diferentes de Cisco CallManager ruteen las llamadas entre sí a través de una nube IP. Cuando conecta dos o más clústers de CallManager multiservidor 3.1.x o 3.2.x, una configuración del trunk incorrecta puede causar problemas con el ruteo de llamadas entre los dos clústers. Cisco ha mejorado y simplificado la configuración en la versión 3.3.x de CallManager.

  • Clúster-a

    • CM-A1

    • CM-A2

    • CM-A3

    • IPPhone-A1 (registrado con el CM-A1)

    • IPPhone-A2 (registrado con el CM-A2)

    • IPPhone-A3 (registradoes con el CM-A3)

  • Clúster-b

    • CM-B1

    • CM-B2

    • IPPhone-B1 (registrado con el CM-B1)

    • IPPhone-B2 (registrado con el CM-B2)

  • Tronco entre clústers

    • ½ DEL ¿Â CM-A1 ï - ½ CM-B1 DEL ¿Â ïÂ

intercluster_1.gif

prerrequisitos

Requisitos

Los Quien lea este documento deben entender cómo administrar las redes CallManageres.

Componentes Utilizados

La información en este documento se basa en la Versión de Callmanager 3.1x, 3.2x, y 3.3x.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Problema

IPPhone-A2 e IPPhone-A3 no pueda realizar ninguna llamadas sobre el tronco entre clústers.

Llamadas de IPPhone IPPhone-B1 IPPhone-B2
IPPhone-A1 El A1 puede llamar el B1 El A1 puede llamar el B2
IPPhone-A2 El a2 no puede llamar el B1 El a2 no puede llamar el B2
IPPhone-A3 El A3 no puede llamar el B1 El A3 no puede llamar el B2

Esto es porque, cuando IPPhone-A2 las tentativas de establecer una llamada, la llamada se inician en el CM-A2 y las puntas al CM-B1. Porque se ha configurado solamente un tronco entre clústers (entre el CM-A1 y el CM-B1), el CM-B1 no es consciente de la existencia del CM-A2 como punto final de H.323. Como consecuencia, la llamada es rechazada por el CM-B1 y falla.

intercluster_2.gif

soluciones 3.1.x o 3.2.x

Hay tres maneras de resolver el problema. Estas soluciones se explican en las siguientes secciones. Además, los pros - y - contra son mencionados para cada solución.

Solución 1 — La creación de un Pseudo-portero en el Clúster-a y el Clúster-b, entonces “permite las llamadas anónimas”

La primera solución implica una configuración de control de acceso que permita los dispositivos anónimos.

Esta solución permite que cada uno de los puntos finales del inter-cluster reciba una llamada entrante de un punto final desconocido de H.323. Así, la llamada del CM-A2 puede ser validada y ser establecida.

Cuando usted configura al portero, complete los campos necesarios según la guía de administración.

Nota: Preste la especial atención a los campos de las llamadas anónimas y del Device Protocol de la permit, que se marcan en esta captura de pantalla:

intercluster_3.gif

Pros

  • Configuración simple — No se requiere ninguna modificación de la configuración de ruteo de llamadas.

  • Scalability — Configuración del único dispositivo.

  • Scalability — Usted necesita solamente configurar un nuevo cluster para conectarlo con la red.

Cons

  • Redundancia — Ninguna redundancia de salida, en caso de error explícitamente de servidores configurados (en este ejemplo, CM-A1 o CM-B1). Solo ruta al cluster remoto.

  • Elegancia — No “limpie” la solución, porque crean a un portero “falso”.

  • precaución Precaución: Puntos finales del tronco entre clústers del permite no identificado (ejemplo: un clúster del Cisco CallManager desconocido) para establecer las llamadas al cluster.

Solución 2 — Configuración explícita de un tronco entre clústers para cada Cisco CallManager remoto

Esta solución le requiere configurar los troncos explícitos entre clústers en cada clúster del Cisco CallManager, que señalan a todo el Cisco Callmanager servers remoto. No es necesario modificar el Call Routing; debe seguir siendo lo mismo que con un solo tronco entre clústers.

intercluster_4.gif

Esta solución permite que cada cluster sea “consciente” de los servidores remotos. Así, la llamada del CM-A2 se valida y se establece.

Pros

  • Configuración simple — No se requiere ninguna modificación de la configuración de ruteo de llamadas.

Cons

  • Redundancia — Ninguna redundancia de salida, en caso de error de servidores primarios (en este ejemplo, CM-A1 o CM-B1).

  • Scalability — Se requiere una interconexión casi total.

  • Scalability — Usted debe configurar de nuevo todos los clusteres cuando un nuevo cluster se agrega a la red.

Solución 3 — Configuración explícita de un tronco entre clústers para cada Cisco CallManager remoto incluido en las Ruta-listas

Esta solución le requiere configurar los troncos explícitos entre clústers en cada clúster del Cisco CallManager, que señalan a todo el Cisco Callmanager servers remoto. Es necesario modificar el Call Routing: cree una lista de la ruta que incluya a un Grupo de Routes que contenga todos los troncos entre clústers configurados, en orden de la preferencia. Esta lista de la ruta debe ser el destino del patrón de ruta que es responsable del ruteo de llamadas entre clústers.

intercluster_4.gif

Esta solución permite que cada cluster sea “consciente” de los servidores remotos. Así, la llamada del CM-A2 se valida y se establece. También permite que las llamadas sean establecidas en los troncos de backup, en caso de que vaya el tronco principal o el servidor abajo.

Pros

  • Redundancia — Redundancia de salida, en caso de error de servidores primarios (en este ejemplo, CM-A1 o CM-B1).

Cons

  • Complejidad — La modificación de la configuración de ruteo de llamadas se requiere.

  • Scalability — Se requiere una interconexión casi total.

  • Scalability — Usted debe configurar de nuevo todos los clusteres cuando un nuevo cluster se agrega a la red.

mejora 3.3.x y configuración

El Cisco CallManager 3.3.x ha introducido una nueva interfaz de la configuración que hace más fácil configurar los troncos entre clústers redundantes, cuando usted debe utilizar el protocolo del tronco entre clústers. En Versiones de Callmanager anteriores, los gatewayes múltiples y una Configuración compleja fueron requeridos, agregar el mismo nivel de Redundancia.

Configuración de un solo tronco entre clústers con IP múltiple los puntos finales

La configuración del tronco entre clústers del Cisco CallManager 3.3.x requiere al administrador crear un solo gateway en cada cluster con los IP Addresses de hasta tres servidores del CallManager remoto. Este solo gateway estará disponible para todos los servidores del CallManager en su cluster respectivo. Para establecer la prioridad, configure el CallManager remoto en la orden que usted prefiere.

intercluster_5.gif

Para más información sobre la configuración de los camiones en el CallManager 3.3x, refiera a la configuración del tronco.


Información Relacionada


Document ID: 19200