Projete uma solução de tronco SIP escalável com vCUSP e CUBE
Introdução
Este documento descreve um projeto de rede de solução que permite troncos de Session Initiation Protocol (SIP) escaláveis para empresas e provedores de serviços. Nessa solução, um Cisco Unified SIP Proxy (CUSP) é usado para agrupar chamadas de entrada e saída em troncos SIP para um pool de roteadores Cisco Unified Border Element (CUBE) .
Contribuição de Andres Salgado, engenheiro técnico de marketing CUBE e Luis Ramirez engenheiro do Cisco TAC
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- CUBO
- TCP
- SIP
- UDP
- CUSP
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Problema
Compartilhamento de carga para vários ambientes de tronco SIP para implantações com vários elementos do CUBE devido aos requisitos de escalabilidade e redundância de um ou vários provedores SIP.
Solução
Visão geral da solução de tronco SIP escalável com vCUSP e (v)CUBE
A sinalização de tronco SIP de entrada de um provedor de serviços é terminada no CUSP. O CUSP distribui as chamadas para um pool de roteadores CUBE, que processam a sinalização de chamadas e configuram sessões de mídia conforme necessário. A capacidade de chamada de tronco SIP pode ser dimensionada simplesmente por um aumento do tamanho do pool do roteador (v)CUBE. Assim, o número de troncos SIP, conforme indicado pelo número de endereços IP para o canal de sinalização, pode ser minimizado para apenas um.
Um segundo CUSP com seu tronco SIP associado pode ser adicionado à solução para apresentar redundância de tronco e balanceamento de carga. O provedor de serviços distribui chamadas pelos dois troncos SIP. Em caso de falha em um CUSP, o provedor de serviços direciona todas as chamadas para outro tronco SIP, evitando, assim, interrupções no serviço. Isso exige que o ping de opções seja ativado no provedor de serviços para monitorar se o tronco SIP está ATIVADO.
Além disso, o pool de roteadores CUBE aumenta a disponibilidade geral da solução. A falha de qualquer CUBE no pool apenas reduz a capacidade de tratamento de chamadas da solução, em vez de causar interrupções no tronco SIP.
O CUSP incorpora recursos do mecanismo de políticas que permitem o roteamento baseado em políticas de chamadas, como o roteamento da hora do dia.
Este guia de design apresenta a arquitetura e os componentes da solução
Descrição da solução
Esta seção descreve a solução de tronco SIP escalável básica. A solução básica fornece balanceamento de carga e escalabilidade de Troncos SIP entre CUBEs.
A solução básica consiste nos próximos elementos:
·Tronco SIP do provedor de serviços.
·UM CUSP
·Quatro roteadores CUBE. Se a demanda por chamadas recebidas aumentar, CUBEs adicionais podem ser adicionados sem alterações necessárias no provedor de serviços ou no Cisco Unified Communications Manager
·O Cisco Unified Communications Manager
· O caminho de sinalização é representado pela linha azul
·Um caminho de mídia para todos os elementos, representado pela linha vermelha
·Roteamento baseado em tabela suportado pelas tabelas de roteamento do CUSP
·As mensagens de manutenção de atividade configuradas usam o comando server-group sip ping-options. O CUSP usa essas mensagens para determinar se um elemento peer está ativo ou inativo e, se ele determina que o elemento está inativo, ele o marca como tal e para interromper as chamadas para ele. Nessa solução, o CUSP usa esse comando para testar as conexões com os pares do provedor de serviços e os roteadores CUBE
Os roteadores CUBE podem usar o comando voice-class sip options-keepalive para verificar o status dos elementos de peer. Você pode obter mais informações sobre esse comando aqui:
Essa solução pode ser desenvolvida a partir de uma topologia básica para uma solução que foi dimensionada para atender ao maior volume de chamadas e que adicionou failover, redundância e roteamento para diferentes provedores de serviços. Você pode ter vários provedores de serviços, vários vCUSPs e vários (v)CUBEs em HA, se necessário.
Diagrama de rede - Solução básica
Adicionar redundância de tronco SIP.
Esta imagem mostra um tronco SIP redundante para o mesmo provedor de serviços. Os troncos SIP redundantes garantem que a sinalização SIP possa ser comutada para o tronco secundário se o tronco principal falhar e que novas solicitações de chamada possam ser tratadas. A redundância também pode ser usada para balanceamento de carga.
Este cenário adiciona estes elementos à topologia de solução básica:
·Um tronco SIP adicional para o provedor de serviços
·UM CUSP
Topologia para Troncos SIP Redundantes do Mesmo Provedor de Serviços
há um CUSP principal e um secundário. Se o tronco com o principal falhar, o provedor de serviços entra em contato com o CUSP secundário.
Topologia para um Tronco SIP de um Segundo Provedor de Serviços
A imagem mostra o provedor de serviços 1 e suas conexões em cores claras para contrastar com o provedor de serviços 2. A figura mostra que o provedor de serviços pode executar o balanceamento de carga, configuração Ativo-Ativo com ambos os CUSPs. Isso pode ser feito pelo conhecimento do provedor de serviços sobre os endereços IP cusp1 e cusp2. Se a tentativa de alcançar o cusp1 falhar, o provedor de serviços fará o roteamento para o cusp2 para assumir a carga adicional.
As políticas de roteamento configuradas no CUSP podem ser usadas para controlar chamadas de saída para o provedor de serviços.
Os provedores de serviços de tronco SIP podem oferecer planos de serviço que cobram taxas de custo de chamadas diferentes, dependendo do destino e da hora do dia. Quando esse for o caso, você poderá rotear chamadas para o provedor de serviços de acordo para aproveitar a taxa mais baixa.
CUBE para CUSP
Métodos diferentes podem ser usados para ter o balanceamento de carga do CUBE entre os Proxies SIP Cisco Unified:
- Um destino de sessão baseado em SRV DNS pode ser configurado para permitir que o CUBE use a prioridade da resposta DNS
- Grupos de servidores em correspondentes de discagem de saída no CUBE. Para usar essa opção com eficiência, você deve configurar o comando voice-class sip options-keepalive profile para monitorar o CUSP associado ao peer de discagem. Se o CUSP estiver no estado inativo, o servidor será marcado como inativo e o CUBE poderá tentar o segundo CUSP sem tentar primeiro o CUSP no estado inativo
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
22-Jan-2019
|
Versão inicial |
Feedback