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

Introdução

Este original descreve o modus operandi usado pelo gerente das comunicações unificadas de Cisco para decidir que que Nós CUCM são usados para enviar chama através do Session Initiation Protocol (SIP) ou dos troncos baseados H.323.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento prévio destes assuntos:

• Conceitos do roteamento básico de chamada dos gerentes das comunicações unificadas de Cisco (CUCM)

Componentes Utilizados

 A informação neste documento é baseada nos gerentes das comunicações unificadas de Cisco (CUCM) 8.x e mais tarde.

 As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos usados neste original começaram com uma configuração cancelada (do padrão). Se sua rede está viva, assegure-se de que você compreenda o impacto potencial do comando any.

Informações de fundo

Os troncos e Gateways H.323 do SORVO não se registram com o CUCM (ao contrário dos gateways MGCP). Em lugar de, o grupo CUCM associado ao pool de dispositivos anexado ao tronco ou ao gateway determina, onde serão ativos. Por exemplo, se são ativos em 2 ou 3 Nós, que mecanismo faz CUCM utilizam para decidir que server para enviar sobre chamar.

O objetivo deste original é explicar como as decisões de roteamento de chamada são feitas e como o Balanceamento de carga pode ser conseguido para chamadas externas através dos troncos ou do H.323 do SORVO.

Mecanismo PRE-CUCM 8.5 de Callrouting (não se usar executada em toda a característica unificada Active dos Nós CM)

Lógica geral: Para uma chamada externa, uma vez que CUCM atravessou a análise de dígitos, estende o atendimento ao RouteList ou ao dispositivo final.  (RouteList obtém registrado a um nó específico, que dependa em cima do grupo CUCM)

O controle de RouteList identifica a lista de dispositivos e pergunta o gerenciador de dispositivo.
O gerenciador de dispositivo dá a identificação de processo do dispositivo (PID) (exemplo: (2,100,25,45), neste exemplo o dispositivo é ativo no nó 2)

O controle de RouteList verifica o estado do dispositivo (são o active do dispositivo de destino, inativos ou os ocupados) e estende o atendimento ao tronco ou ao gateway.

Desde que os troncos do SORVO/Gateways H.323 podem ser ativos em nós múltiplos, a pergunta implora agora que nó é selecionado como o PID ativo pelo gerenciador de dispositivo?

Estas encenações do uso-caso derramaram uma luz mais adicional nesta:

Uso-caso 1: Telefones IP registrados a Nó1. Nenhum RouteList configurou.

Neste SORVO o tronco é ativo no nó 1 e 4.

• A lógica geral permanece a mesma, CUCM faz a análise de dígitos no nó 1 onde o telefone é registrado. Desde que nenhum RouteList é configurado, a rota padrão é associada diretamente ao tronco do SORVO.
  
  
• CUCM no nó 1 pergunta o gerenciador de dispositivo no nó 1.
  
  
• Tabela local da verificação do gerenciador de dispositivo (DM) sempre primeiramente, e dispositivo local do retorno se há um, para evitar uma comunicação/tráfego inter desnecessários do conjunto.

Neste caso, o tronco do SORVO é ativo no nó 1 onde o telefone é registrado assim que CUCM estende o atendimento do nó 1 (todas as vezes). A lógica aleatória não é aplicada aqui e ali é nenhum Balanceamento de carga desde que o atendimento é prolongado de Nó1 em todos os casos.

Uso-caso 2: Telefones IP registrados ao nó 1. RouteList registrado ao nó 2.

Neste SORVO o tronco é ativo no nó 2 e 4.

• Após resultados da análise de dígitos (a Dinamarca), o nó 1 CUCM estende o atendimento ao controle de RouteList no nó 2.
  
  
• O controle de RouteList no nó 2 pergunta o gerenciador de dispositivo no nó 2.
  
  
• O DM verifica sempre a tabela local primeiramente, e retorna um dispositivo local se há um, neste caso o tronco do SORVO é local ao nó 2.

Em consequência, não importa onde o telefone é registrado, desde que o RouteList é registrado ao nó 2 e tronco do sorvo é ativo no mesmo nó, todos os atendimentos é fonte do nó 2. Além disso, a lógica aleatória não é aplicada.

Uso-caso 3: Telefones IP registrados ao nó 1. RouteList registrado ao nó 2.

Este em H323 gateway é ativo em Nó1 e em 4.

• Após resultados Dinamarca, CUCM no nó 1 estende o atendimento ao controle de RouteList no nó 2.
  
  
• O controle de RouteList no nó 2 pergunta o gerenciador de dispositivo no nó 2.
  
  
• O gerenciador de dispositivo (DM) verifica sempre a tabela local primeiramente, e retorna o dispositivo local nenhuns.
  
  
• O gerenciador de dispositivo olha acima RemoteTable, e vê o active do gateway de H.323 no nó 1 e 4.

Aplica a lógica aleatória, e dá um PID ativo aleatoriamente ao controle de RouteList. Desde que é enviado aleatoriamente entre o nó 1 e 4, os atendimentos são carga equilibrada em CUCM.

Conclusão

CUCM verifica se o gateway do SORVO trunk/H.323 seja ativo no mesmo nó que o dispositivo chamando. Em caso afirmativo, então usa sempre o nó local para enviar chamar.
Se o gateway do SORVO trunk/H.323 não é ativo no mesmo nó que o dispositivo chamando, a seguir ele fontes aleatoriamente dos Nós onde o tronco/dispositivo é ativos.

Note: O dispositivo chamando pode ser um telefone ou um RouteList.  Se a rota padrão está combinando um RouteList, a seguir a chamada originada é o RouteList. Se a rota padrão é associada diretamente ao dispositivo SIP/H.323, a seguir a chamada originada é o telefone.

Balanceamento de carga

Se o Balanceamento de carga quer ser conseguido, a seguir não é aconselhável coimplantar o RouteList ou o telefone com os Nós CUCM que os gateways SIP/H.323 estão associados a isto é se são ambos active no mesmo nó, a seguir os atendimentos estarão mandados do nó local (sempre).

Ou seja o gateway do SORVO trunk/H.323 precisa de ser configurado tais que não são ativos nos Nós onde o RouteList ou os telefones são registrados.

Da versão 8.6 CUCM avante, CUCM introduziu os novos recursos chamados corrida em todos os Nós unificados active CM para ambos os troncos RouteList/SIP.     

Esta é uma outra maneira de carregar eficientemente o equilíbrio as chamadas externas e reduz o número de sinais trocou dentro do conjunto.

Cargo-CUCM 8.5 do mecanismo de Callrouting (a corrida em todos os Nós unificados active CM caracteriza sendo usado)

Em CUCM 8.5 e acima de Cisco introduziu uns novos recursos em troncos do sorvo e a corrida chamada lista da rota em todo o active unificou Nós CM. Isto removeu basicamente a dependência do tronco do sorvo e a lista da rota no grupo CUCM atribuiu-lhes. Isto implica que você pode ter mais de três server CUCM de que origine e termine atendimentos e a um tronco do sorvo.

Troncos do SORVO – Seja executado em todos os Nós e na regra do Local da rota

Quando sido executado em toda a opção unificada Active dos Nós CM é verificado em um tronco do SORVO, unificado CM cria um exemplo do demônio do tronco do SORVO em cada subscritor do Processamento de chamadas dentro do conjunto, assim permitindo que um atendimento de tronco do SORVO seja feito ou recebido em todo o subscritor do Processamento de chamadas. (Antes desta característica, até três Nós poderiam ser selecionados pelo tronco usando grupos unificados CM.)

Com corrida em todo o Active unificou os Nós CM permitidos, os atendimentos de tronco de partida do SORVO originam do mesmo nó em que a chamada recebida (por exemplo, de um telefone ou de um tronco) é recebida (baseado na regra local da rota). A corrida em toda a característica unificada Active dos Nós CM cancela a configuração de grupo unificada CM do tronco.

Para troncos do SORVO, isto é como a regra local da rota se opera:

Para atendimentos de tronco de partida do SORVO, quando um atendimento de um telefone registrado ou de um tronco de entrada chega em um nó unificado CM, unificado CM verifica para ver se um exemplo do tronco de partida selecionado existe no mesmo nó onde a chamada recebida chegou. Em caso afirmativo, unificado CM usa este nó para estabelecer o atendimento de tronco de partida.

Para permitir a corrida em todos os Nós unificados Active CM em troncos do SORVO é altamente recomendado porque esta característica permite que as chamadas externas originem de, e seja recebida sobre, todo o nó do Processamento de chamadas dentro do conjunto. Seja executado em todos os Nós unificados Active CM pode igualmente eliminar atendimentos de estabelecer-se entre Nós do Processamento de chamadas dentro do mesmo conjunto antes de ser estabelecido sobre o tronco de partida do SORVO.

Como com todos os troncos unificados do SORVO CM, os demônios do SORVO associados com o tronco aceitam chamadas recebidas somente dos sistemas finais com IP address que são definidos nos campos de endereço de destino do tronco.

Quando os troncos múltiplos do SORVO aos mesmos destinos estão usando os Nós do processamento de mesma chamada, um entrante e um número de porta de destino originais devem ser definidos pelo tronco para permitir que cada tronco seja identificado excepcionalmente.

Lista da rota – Seja executado em todos os Nós e na regra do Local da rota

Embora esta não seja especificamente uma característica do tronco do SORVO, que executa a rota lista em todos os Nós fornece benefícios para troncos em lista e em grupos de rotas da rota. As lista running da rota em todos os Nós melhoram a distribuição de chamada externa usando a regra local da rota para evitar o tráfego desnecessário da instalação de chamada de intra-grânulo.

Para lista da rota, isto é como a regra local da rota se opera:

Para as chamadas externas que usam lista da rota (e grupos de rotas e troncos associados), quando um atendimento de um telefone registrado ou de um tronco de entrada chega no nó com o exemplo da lista da rota, unificou verificações CM para ver se um exemplo do tronco de partida selecionado existe no mesmo nó que a lista da rota. Em caso afirmativo, unificado CM usa este nó para estabelecer o atendimento de tronco de partida.

• Se a lista da rota e o tronco foram executado em todos os Nós unificados Active CM permitidos, a distribuição de chamada externa está determinada pelo nó em que a chamada recebida chega.
  
  
• Se o tronco de partida selecionado usa grupos unificados CM em vez de ser executado em todos os Nós, unificados CM aplica a regra local da rota se um exemplo do tronco de partida selecionado existe no mesmo nó em que a chamada recebida chega.
  
  
• Se um exemplo do tronco não existe neste nó, a seguir unificado o CM para a frente o atendimento (dentro do conjunto) a um nó onde o tronco seja ativo.
  
  
• Se a lista da rota não foi executado em todos os Nós unificados Active CM permitidos, um exemplo da lista da rota será ativo em um nó dentro do conjunto (o nó principal do grupo unificado CM da lista da rota).
  
  
• Se o tronco de partida selecionado é igualmente ativo no nó principal do grupo unificado CM da lista da rota, a regra local da rota é aplicada, tendo por resultado a distribuição de chamada externa secundário-ótima porque todos os atendimentos de tronco de partida originam deste nó.

Cisco recomenda fortemente a possibilidade executada em todos os Nós unificados Active CM em todas as lista da rota e troncos do SORVO.