Mecanismo de distribuição de chamadas CUCM no tronco SIP/H323

Introduction

Este documento descreve o modus operandi usado pelo Cisco Unified Communications Manager para decidir quais nós do CUCM são usados para enviar chamadas através de troncos baseados em SIP (Session Initiation Protocol) ou H.323.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento prévio destes tópicos:

• Conceitos básicos de roteamento de chamadas do Cisco Unified Communications Managers (CUCM)

Componentes Utilizados

 As informações neste documento são baseadas no Cisco Unified Communications Managers (CUCM) 8.x e posterior.

 The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Os troncos SIP e os gateways H.323 não se registram no CUCM (ao contrário dos gateways MGCP). Em vez disso, o grupo CUCM associado ao pool de dispositivos conectados ao tronco ou gateway determina onde eles estarão ativos. Por exemplo, se eles estiverem ativos em 2 ou 3 nós, qual mecanismo o CUCM utiliza para decidir em qual servidor enviar a chamada.

O objetivo deste documento é explicar como as decisões de roteamento de chamadas são tomadas e como o balanceamento de carga pode ser alcançado para chamadas de saída via Troncos SIP ou H.323.

Mecanismo de roteamento de chamadas Pre-CUCM 8.5 (não usando o recurso Executar em todos os nós do Ative Unified CM)

Lógica geral: Para uma chamada de saída, depois que o CUCM passa pela análise de Dígito, ele estende a chamada para a RouteList ou o dispositivo final.  (RouteList é registrado em um nó específico, que depende do grupo CUCM)

O controle RouteList identifica a lista de dispositivos e consulta o gerenciador de dispositivos.
O gerenciador de dispositivos fornece ID de processo (PID) do dispositivo (exemplo: (2.100.25.45), neste exemplo, o dispositivo está ativo no nó 2)

O controle RouteList verifica o status do dispositivo (é o dispositivo de destino ativo, ocioso ou ocupado) e estende a chamada para o tronco ou gateway.

Como os troncos SIP / Gateways H.323 podem estar ativos em vários nós, a pergunta agora é qual nó é selecionado como PID ativo pelo gerenciador de dispositivos?

Esses cenários de caso de uso lançam mais luz sobre isso:

Caso de uso 1: Telefones IP registrados no nó 1. Nenhuma lista de rotas configurada.

Neste Tronco SIP está ativo nos nós 1 e 4.

• A lógica geral permanece a mesma, o CUCM faz a análise de dígito no nó 1 onde o telefone está registrado. Como nenhuma RouteList está configurada, o Route Pattern está diretamente associado ao tronco SIP.
  
  
• O CUCM no nó 1 consulta o Gerenciador de dispositivos no nó 1.
  
  
• O Gerenciador de dispositivos (DM) sempre verifica a Tabela local primeiro e retorna o dispositivo local se houver, para evitar comunicações/tráfego desnecessários entre clusters.

Nesse caso, o tronco SIP está ativo no nó 1 em que o telefone está registrado, de modo que o CUCM estenda a chamada do nó 1 (toda vez). A lógica aleatória não é aplicada aqui e não há balanceamento de carga porque a chamada é estendida do Nó 1 em cada caso.

Caso de uso 2: Telefones IP registrados no nó 1. RouteList Registered to Node 2.

Neste Tronco SIP está ativo nos nós 2 e 4.

• Após os resultados da Análise de Dígito (DA), o nó 1 do CUCM estende a chamada para o Controle da Lista de Rotas no nó 2.
  
  
• RouteList Control no nó 2 consulta o gerenciador de dispositivos no nó 2.
  
  
• O DM sempre verifica a Tabela Local primeiro e retorna um dispositivo local se houver um, nesse caso o tronco SIP é local para o nó 2.

Como resultado, não importa onde o telefone esteja registrado, já que RouteList está registrado no nó 2 e o tronco Sip está ativo no mesmo nó, todas as chamadas são origem do nó 2. Novamente, a lógica aleatória não é aplicada.

Caso de uso 3: Telefones IP registrados no nó 1. RouteList Registered to Node 2.

Nesse gateway H323 está ativo nos nós 1 e 4.

• Depois dos resultados do DA, o CUCM no nó 1 estende a chamada para o controle RouteList no nó 2.
  
  
• O controle RouteList no nó 2 consulta o Gerenciador de dispositivos no nó 2.
  
  
• O Gerenciador de dispositivos (DM) sempre verifica a Tabela local primeiro e retorna nenhum dispositivo local.
  
  
• O Gerenciador de dispositivos procura RemoteTable e vê o Gateway H.323 ativo nos nós 1 e 4.

Aplica a lógica aleatória e fornece um PID ativo aleatoriamente para o controle RouteList. Como é enviada aleatoriamente entre os nós 1 e 4, as chamadas são balanceadas no CUCM.

Conclusão

O CUCM verifica se o tronco SIP/gateway H.323 está ativo no mesmo nó que o dispositivo chamador. Se sim, ele sempre usa o nó local para enviar a chamada.
Se o gateway de tronco SIP/H.323 não estiver ativo no mesmo nó do dispositivo chamador, ele será gerado aleatoriamente dos nós onde o tronco/dispositivo está ativo.

Note: O dispositivo chamador pode ser um telefone ou uma RouteList.  Se o padrão de rota corresponder a RouteList, a parte chamadora será RouteList. Se o padrão de rota estiver associado diretamente ao dispositivo SIP/H.323, o chamador será o telefone.

Balanceamento de carga

Se o balanceamento de carga quiser ser alcançado, não é aconselhável colocar a RouteList ou o telefone junto aos nós CUCM aos quais os gateways SIP/H.323 estão associados, ou seja, se ambos estiverem ativos no mesmo nó, então as chamadas serão enviadas do nó local (sempre) .

Em outras palavras, o tronco SIP/gateway H.323 precisa ser configurado para que não estejam ativos nos nós em que RouteList ou telefones estão registrados.

A partir da versão 8.6 do CUCM, o CUCM introduziu um novo recurso chamado Executar em todos os nós do Unified CM ativos para ambos os troncos RouteList/SIP.     

Essa é outra forma de balancear a carga com eficiência das chamadas de saída e reduzir o número de sinais trocados no cluster.

Mecanismo de roteamento de chamadas pós-CUCM 8.5 (Executar em todos os nós do Unified CM ativos em uso)

No CUCM 8.5 e acima, a Cisco introduziu um novo recurso em troncos sip e na lista de rotas chamada Executar em todos os nós CM unificados ativos. Isso basicamente removeu a dependência do tronco sip e a lista de rotas no grupo CUCM atribuído a eles. Isso significa que você pode ter mais de três servidores CUCM que originam e terminam chamadas de e para um tronco sip.

Troncos SIP - executados em todos os nós e na regra local da rota

Quando a opção Executar em todos os nós do Ative Unified CM é verificada em um tronco SIP, o Unified CM cria uma instância do daemon de tronco SIP em cada assinante de processamento de chamada no cluster, permitindo assim que uma chamada de tronco SIP seja feita ou recebida em qualquer assinante de processamento de chamada. (Antes deste recurso, até três nós poderiam ser selecionados por tronco usando Grupos Unified CM.)

Com a opção Executar em todos os nós Ative Unified CM ativada, as chamadas de tronco SIP de saída são originadas do mesmo nó no qual a chamada de entrada (por exemplo, de um telefone ou tronco) é recebida (com base na regra Route Local). O recurso Executar em todos os nós do Ative Unified CM substitui a configuração do grupo do Unified CM do tronco.

Para troncos SIP, é assim que a regra Route Local opera:

Para chamadas de tronco SIP de saída, quando uma chamada de um telefone registrado ou tronco de entrada chega a um nó do Unified CM, o Unified CM verifica se existe uma instância do tronco de saída selecionado no mesmo nó em que a chamada de entrada chegou. Se sim, o Unified CM usa esse nó para estabelecer a chamada de tronco de saída.

Habilitar Executar em todos os nós Ative Unified CM em troncos SIP é altamente recomendado porque esse recurso permite que as chamadas de saída sejam originadas e recebidas em qualquer nó de processamento de chamadas no cluster. Executar em todos os nós do Ative Unified CM também pode eliminar as chamadas de serem configuradas entre os nós de processamento de chamadas no mesmo cluster antes de serem estabelecidas no tronco SIP de saída.

Como com todos os troncos SIP do Unified CM, os daemons SIP associados ao tronco aceitam chamadas de entrada somente de sistemas finais com endereços IP definidos nos campos de endereço de destino do tronco.

Quando vários troncos SIP para o mesmo destino estão usando os mesmos nós de processamento de chamada, um número de porta de entrada e de destino exclusivo deve ser definido por tronco para permitir que cada tronco seja identificado de forma exclusiva.

Listas de rota - executadas em todos os nós e na regra local da rota

Embora não seja especificamente um recurso de tronco SIP, a execução de listas de rotas em todos os nós oferece benefícios para troncos em listas de rotas e grupos de rotas. A execução de listas de rotas em todos os nós melhora a distribuição de chamadas de saída usando a regra Route Local para evitar tráfego desnecessário de configuração de chamadas entre clusters.

Para listas de rotas, é assim que a regra Local da Rota opera:

Para chamadas de saída que usam listas de rotas (e grupos de rotas e troncos associados), quando uma chamada de um telefone registrado ou tronco de entrada chega no nó com a instância da lista de rotas, o Unified CM verifica se existe uma instância do tronco de saída selecionado no mesmo nó da lista de rotas. Se sim, o Unified CM usa esse nó para estabelecer a chamada de tronco de saída.

• Se a lista de rotas e o tronco tiverem Executar em todos os nós Ative Unified CM ativados, a distribuição de chamadas de saída será determinada pelo nó em que a chamada de entrada chegar.
  
  
• Se o tronco de saída selecionado usar grupos do Unified CM em vez de ser executado em todos os nós, o Unified CM aplicará a regra Route Local se uma instância do tronco de saída selecionado existir no mesmo nó em que a chamada de entrada chega.
  
  
• Se uma instância do tronco não existir nesse nó, o Unified CM encaminhará a chamada (dentro do cluster) para um nó onde o tronco está ativo.
  
  
• Se a lista de rotas não tiver a opção Executar em todos os nós do Ative Unified CM habilitados, uma instância da lista de rotas estará ativa em um nó no cluster (o nó principal do grupo do Unified CM da lista de rotas).
  
  
• Se o tronco de saída selecionado também estiver ativo no nó primário do grupo Unified CM da lista de rotas, a regra Route Local será aplicada, resultando na distribuição de chamadas de saída abaixo do ideal porque todas as chamadas de tronco de saída se originam desse nó.

A Cisco recomenda habilitar Executar em todos os nós Ative Unified CM em todas as listas de rotas e troncos SIP.