Fundamentos

Pré-requisitos

Antes de implantar o CUBE HA como um gateway local para o Webex Calling, certifique-se de ter uma compreensão mais profunda dos seguintes conceitos:

As diretrizes de configuração fornecidas neste artigo assumem uma plataforma de gateway local dedicada sem configuração de voz existente. Se uma implantação empresarial do CUBE existente estiver sendo modificada para utilizar também a função de gateway local do Cisco Webex Calling, preste atenção à configuração aplicada para garantir que os fluxos e funcionalidades de chamada existentes não sejam interrompidos e certifique-se de que você esteja aderindo aos requisitos de projeto CUBE HA.

Componentes de hardware e software

CUBE HA como gateway local exige o IOS-XE versão 16.12.2 ou posterior e uma plataforma na qual as funções CUBE HA e LGW são suportadas.

Os comandos e os registros de apresentação neste artigo baseiam-se na versão mínima de software do Cisco IOS-XE 16.12.2 implementado em um vCUBE (CSR1000v).

Material de referência

Aqui estão alguns guias detalhados de configuração DO CUBE HA para várias plataformas:

Webex Calling geral da solução

Cisco Webex Calling é uma oferta de colaboração que fornece uma alternativa baseada em nuvem para vários locatários ao serviço telefônico PBX no local, com várias PSTN para os clientes.

A implantação do Gateway local (representado abaixo) é o foco deste artigo. O tronco gateway local (PSTN) no Webex Calling permite conectividade a um serviço de PSTN cliente. Ele também fornece conectividade para uma implantação de PBX de IP no local, como o Cisco Unified CM. Toda a comunicação para e da nuvem é protegida usando o transporte TLS para SIP e SRTP para mídia.

A figura abaixo exibe uma implantação Webex Calling sistema sem qualquer PBX de IP existente e é aplicável a uma única ou várias implantações de sites. Configuração descrita neste artigo é baseada nesta implantação.

Redundância caixa a caixa da camada 2

A redundância box-to-box do CUBE HA layer 2 usa o protocolo de infraestrutura de Grupo de Redundância (RG) para formar um par de roteadores ativos/em espera. Este par compartilha o mesmo endereço de IP virtual (VIP) em suas respectivas interfaces e trocam continuamente mensagens de status. As informações da sessão do CUBE são verifique-se primeiro entre o par de roteadores permitindo que o roteador de espera leve todas as responsabilidades de processamento de chamada do CUBE imediatamente se o roteador ativo sair do serviço, resultando em preservação estado da sinalização e da mídia.

A verificação apontando está limitada a chamadas conectadas com pacotes de mídia. As chamadas em trânsito não são marque a consulta (por exemplo, um estado de tentativa ou toque).

Neste artigo, CUBE HA irá se referir à Redundância Box-to-box (HA) CUBE High Availability (HA) para redundância preservação da chamada

A partir do IOS-XE 16.12.2, o CUBE HA pode ser implantado como um Gateway local para implantações de troncos Cisco Webex Calling (baseado no local PSTN) e cobriremos as considerações e configurações do projeto neste artigo. Esta figura exibe uma configuração TÍPICA DO CUBE HA como Gateway Local para uma implantação Cisco Webex Calling tronco.

Componente Infra do Grupo de Redundância

O componente Infra do Grupo de Redundância (RG) fornece o suporte à infraestrutura de comunicação box-a-box entre os dois CUBEs e negociará o estado de redundância final estável. Este componente também fornece:

  • Um protocolo em forma HSRP que negociará o estado de redundância final para cada roteador, trocando mensagens de mantenha-se ativos e olá entre os dois CUBES (através da interface de controle)—GigabitEthernet3 na figura acima.

  • Um mecanismo de transporte para o verificação do estado de sinalização e mídia para cada chamada dos ativos para o roteador de espera (através da interface de dados)—GigabitEthernet3 na figura acima.

  • Configuração e gerenciamento da interface ip virtual (VIP) para as interfaces de tráfego (várias interfaces de tráfego podem ser configuradas usando o mesmo grupo RG) - GigabitEthernet 1 e 2 são considerados interfaces de tráfego.

Este componente RG tem que ser configurado especificamente para suportar ha de voz B2B.

Gerenciamento de endereços IP virtual (VIP) para sinalização e mídia

A HA B2B depende do VIP para alcançar a redundância. As interfaces físicas VIP e associadas em ambos OS CUBEs no par HA do CUBE devem residir na mesma sub-rede LAN. A configuração do VIP e a associação da interface VIP para um aplicativo de voz específico (SIP) são obrigatórias para o suporte ha B2B de voz. Dispositivos externos como Unified CM, Webex Calling acesso SBC, provedor de serviços ou proxy, use VIP como endereço de IP de destino para as chamadas que atravessam os roteadores CUBE HA. Portanto, a partir Webex Calling ponto de vista, os pares CUBE HA atua como um único gateway local.

A sinalização de chamadas e as informações da sessão RTP das chamadas estabelecidas são pontos de controle a partir do roteador ativo para o roteador em espera. Quando o roteador Ativo cair, o roteador Em espera assume o controle e continua a encaminhar o fluxo RTP que foi previamente roteado pelo primeiro roteador.

As chamadas em um estado transitório no momento do failover não serão preservadas após a mudança. Por exemplo, chamadas que ainda não estão totalmente estabelecidas ou estão em processo de ser modificadas com uma função de transferência ou espera. As chamadas estabelecidas podem ser desconectadas após a mudança.

Os seguintes requisitos existem para usar o CUBE HA como um gateway local para failover estado de chamadas:

  • CUBE HA não pode ter TDM ou interfaces analógicos co-localizadas

  • Gig1 e Gig2 são referidos como interfaces de tráfego (SIP/RTP) e Gig3 é interface de controle/dados do grupo de redundância (RG)

  • Não mais do que 2 pares DE CUBE HA podem ser colocados no mesmo domínio da camada 2, um com ID de grupo 1 e o outro com ID de grupo 2. Se configurar 2 pares HA com a mesma ID de grupo, as interfaces de controle RG/dados precisarão pertencer a diferentes domínios da camada 2 (vlan, comutamento separado)

  • O canal da porta é suportado para as interfaces de controle/dados e tráfego RG

  • Toda sinalização/mídia é fonte de/para o endereço ip virtual

  • A qualquer momento, uma plataforma é recarregada em uma relação CUBE-HA, ela sempre inicializa como Modo de espera

  • O endereço mais baixo para todas as interfaces (Gig1, Gig2, Gig3) deve estar na mesma plataforma

  • Identificador da interface de redundância, o rii deve ser exclusivo para uma combinação de emparelhamento/interface na mesma camada 2

  • A configuração no CUBEs deve ser idêntica, incluindo a configuração física e deve estar executando no mesmo tipo de plataforma e da versão IOS-XE

  • As interfaces de retorno de loop não podem ser usadas como vincular, uma vez que estão sempre atualizadas

  • As interfaces de múltiplos tráfegos (SIP/RTP) (Gig1, Gig2) requerem o rastreamento da interface para serem configuradas

  • CUBE-HA não é suportado por uma conexão de cabo remoto para o link de controle/dados RG (Gig3)

  • Ambas as plataformas devem ser idênticas e conectadas através de um Switch físico através de todas as interfaces da mesma forma para que a CUBE HA funcione, ou seja, GE0/0/0 de CUBE-1 e CUBE-2 deve terminar no mesmo interruptor e assim por diante.

  • Não é possível ter WAN encerrado no CUBEs diretamente ou Data HA de um dos lados

  • Ambos ativos/em espera devem estar no mesmo centro de dados

  • É obrigatório usar a interface L3 separada para redundância (Controle RG/dados, Gig3). ou seja, a interface usada para o tráfego não pode ser usada para keep infra-calendários e controle de controle de HA

  • Após o failover, o CUBE anteriormente ativo passa por uma recarregação pelo design, preservando a sinalização e a mídia

Configurar a redundância em ambos OS CUBEs

Você deve configurar a redundância caixa a caixa 2 em ambos OS CUBEs destinados a ser usados em um par HA para trazer IPs virtuais.

1

Configure o rastreamento da interface em um nível global para rastrear o status da interface.

track t track 1 interface GigabitEthernet1 faixa de protocolo de linha 
 
 2 interface GigabitEthernet2 saída de protocolo de linha

VCUBE-1#conf t
VCUBE-1(configuração)#faixa 1 interface GigabitEthernet1 protocolo de linha
VCUBE-1(config-track)# faixa2 interface GigabitEthernet2 line-protocol
VCUBE-1(config-track)#sair
 
VCUBE-2#conf t
VCUBE-2(configuração)#faixa 1 interface GigabitEthernet1 protocolo de linha
VCUBE-2(config-track)# faixa2 interface GigabitEthernet2 line-protocol
VCUBE-2(config-track)#sair

ClI da faixa é usada no RG para rastrear o estado da interface do tráfego de voz de modo que a rota ativa manterá sua função ativa após a interface do tráfego estar inativa.
2

Configure um RG para uso com VoIP HA no sub-modo de redundância de aplicativos.

redundância do aplicativo de redundância grupo 
 
 
    1 nome LocalGateway-HA prioridade 
    100 failover limiar 75 controle 
    GigabitEthernet3 protocolo 1 data GigabitEthernet3 temporizadores de atraso 30 recarregam 60 faixa 1 de desligamento 2 desligamento protocolo de saída 
 
 
 
 
 
   1 
    temporizadores hellotime 3 holdtime 10 
 
 
 sair sair

VCUBE-1(configuração)#redundância
VCUBE-1(config-red)#redundância do aplicativo
VCUBE-1(config-red-app)#grupo 1
VCUBE-1(config-red-app-grp)#nome LocalGateway-HA
VCUBE-1(config-red-app-grp)# prioridade100 limite de failover 75
VCUBE-1(config-red-app-grp)#protocolo de controle GigabitEthernet3 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-1(config-red-app-grp)#temporizadores atraso 30 recarregam 60
VCUBE-1(config-red-app-grp)#faixa 1 de desligamento
VCUBE-1(config-red-app-grp)#faixa 2 de desligamento
VCUBE-1(config-red-app-grp)#sair
VCUBE-1(config-red-app)#protocolo 1
VCUBE-1(config-red-app-prtcl)#temporizadores hellotime 3 holdtime 10
VCUBE-1(config-red-app-prtcl)#sair
VCUBE-1(config-red-app)#sair
VCUBE-1(config-red)#sair
VCUBE-1(configuração) #
 
VCUBE-2(configuração)#redundância
VCUBE-2(config-red)#redundância do aplicativo
VCUBE-2(config-red-app)#grupo 1
VCUBE-2(config-red-app-grp)#nome LocalGateway-HA
VCUBE-2(config-red-app-grp)# prioridade100 limite de failover 75
VCUBE-2(config-red-app-grp)#protocolo de controle GigabitEthernet3 1
VCUBE-1(config-red-app-grp)#data GigabitEthernet3
VCUBE-2(config-red-app-grp)#temporizadores atraso 30 recarregam 60
VCUBE-2(config-red-app-grp)#acompanhar 1 desligamento
VCUBE-2(config-red-app-grp)#faixa 2 de desligamento
VCUBE-2(config-red-app-grp)#sair
VCUBE-2(config-red-app)#protocolo 1
VCUBE-2(config-red-app-prtcl)#temporizadores hellotime 3 holdtime 10
VCUBE-2(config-red-app-prtcl)#sair
VCUBE-2(config-red-app)#sair
VCUBE-2(config-red)#sair
VCUBE-2(configuração) #

Aqui está uma explicação dos campos usados nesta configuração:

  • redundância— Insicar o modo de redundância

  • redundância do aplicativo— Inssi sobre o modo de configuração de redundância de aplicativos

  • grupo— Insicar o modo de configuração do grupo de aplicativos de redundância

  • nome LocalGateway-HA— Define o nome do grupo RG

  • prioridade 100 failover limite 75 — especifica os limites de prioridade inicial efailover para um RG

  • temporizadores atraso 30 recarregam 60— configura as duas vezes para atraso e recarregamento

    • Temporizador de atraso que é a quantidade de tempo para atrasar a inicialização e a negociação de papéis do grupo RG após a interface aparecer – Padrão 30 segundos. O intervalo é de 0-10000 segundos

    • Recarrege - Esta é a quantidade de tempo para atrasar a inicialização e a negociação de papéis do grupo RG após uma recarregamento – Padrão 60 segundos. O intervalo é de 0-10000 segundos

    • Os temporizadores padrão são recomendados, embora esses temporizadores possam ser ajustados para acomodar qualquer atraso adicional na convergência da rede que possa ocorrer durante a inicialização/recarregamento dos roteadores, a fim de garantir que a negociação do protocolo RG ocorra após o roteamento na rede ter convergido para um ponto estável. Por exemplo, se for visto após o failover que leva até 20 seg para o novo STANDBY ver o primeiro pacote OLÁ do RG do novo ATIVO, então os temporizadores devem ser ajustados para "temporizadores atrasarem 60 atraso 120" para fatores nesse atraso.

  • controlar o protocolo GigabitEthernet3 1 —Configura a interface usada para trocar mensagens de mantenhaaliveis e olá entre os dois CUBEs, e especifica a ocorrência de protocolo que será anexada a uma interface de controle e entra no modo de configuração de protocolo de aplicativo deredundância

  • GigabitEthernet3 de dados— Configura a interface usada para o controle de tráfego de dados

  • faixa— Rastreamento de grupos RG de interfaces

  • protocolo 1 — Especifica a ocorrência de protocolo que será anexada a uma interface de controle e entra no modo de configuração do protocolo de aplicativo deredundância

  • temporizadores hellotime 3 holdtime 10— Configura os dois temporizadores para hellotime e holdtime:

    • Hellotime — Intervalo entre as mensagens de olá sucessivos – Padrão 3 segundos. O intervalo é de 250 milissegundos-254 segundos

    • Tempo de espera — O intervalo entre o recebimento de uma mensagem de Olá e a suposição de que o roteador de envio falhou. Essa duração tem que ser maior do que o tempo de saudação - 10 segundos padrão. O intervalo é de 750 milissegundos-255 segundos

      Recomendamos que você configure o temporizador de tempo de espera para ser pelo menos 3 vezes o valor do temporizador de hellotime.
3

Ative a redundância box-to-box para o aplicativo CUBE. Configure o RG a partir da etapa anterior em voip de serviço devoz. Isto permite que o aplicativo CUBE controle o processo de redundância.

voip serviço de voz 
   redundância-grupo 1 
   sair
VCUBE-1(configuração)#voip do serviço de voz
VCUBE-1(config-voi-serv)#redundância-grupo 1

  % Criado RG 1 associação com voz B2B HA; recarregar o roteador para que a nova configuração entre em vigor

VCUBE-1(config-voi-serv)# sair
 
VCUBE-2(configuração)#voip do serviço de voz
VCUBE-2(config-voi-serv)#redundância-grupo 1

  % Criado RG 1 associação com voz B2B HA; recarregar o roteador para que a nova configuração entre em vigor

VCUBE-2(config-voi-serv)# sair

redundância-grupo 1 — Adicionar e remover este comando requer umarecarga para que a configuração atualizada entre em vigor. Recarregaremos as plataformas depois que todas as configurações já foram aplicadas.
4

Configure as interfaces Gig1 e Gig2 com seus respectivos IPs virtuais, conforme mostrado abaixo, e aplique o identificador da interface deredundância (rii)

VCUBE-1(configuração)#interface GigabitEthernet1
VCUBE-1(config-if)# redundância rii 1
VCUBE-1(config-if)# grupo de redundância 1 ip 198.18.1.228 exclusivo
VCUBE-1(configuração-se)# sair
VCUBE-1(configuração) #
VCUBE-1(configuração)#interface GigabitEthernet2
VCUBE-1(config-if)# redundância rii 2
VCUBE-1(config-if)# grupo de redundância 1 ip 198.18.133.228 exclusivo
VCUBE-1(configuração-se)# sair
 
VCUBE-2(configuração)#interface GigabitEthernet1
VCUBE-2(config-if)# redundância rii 1
VCUBE-2(config-if)# grupo de redundância 1 ip 198.18.1.228 exclusivo
VCUBE-2(configuração-se)# sair
VCUBE-2(configuração) #
VCUBE-2(configuração)#interface GigabitEthernet2
VCUBE-2(config-if)# redundância rii 2
VCUBE-2(config-if)# grupo de redundância 1 ip 198.18.133.228 exclusivo
VCUBE-v(config-if)# sair

Aqui está uma explicação dos campos usados nesta configuração:

  • redundância rii—Configura o identificador da interface de redundância para o grupo de redundância. Necessário para gerar um endereço MAC (VMAC) Virtual. O mesmo valor de ID rii deve ser usado na interface de cada roteador (ACTIVE/STANDBY) que tem o mesmo VIP.


     

    Se houver mais de um par B2B na mesma LAN, cada par DEVE ter IDs de rii exclusivas em suas respectivas interfaces (para evitar a colisão). "mostrar todos os grupos de aplicativos de redundância" devem indicar as informações corretas locais e de pares.

  • redundância do grupo 1 — Associa a interface com ogrupo de redundância criado na Etapa 2 acima. Configure o grupo RG, bem como o VIP atribuído a esta interface física.


     

    É obrigatório usar uma interface separada para redundância, ou seja, a interface usada para o tráfego de voz não pode ser usada como interface de controle e dados especificada na Etapa 2 acima. Neste exemplo, a interface de Gigabit 3 é usada para o controle/dados de RG
5

Salve a configuração do primeiro CUBE e recarregue-o.

A plataforma para recarregar por último é sempre a de Espera.

VCUBE-1#wr

  Configuração de edifício...


  [OK]

VCUBE-1#recarregou

  Prosseguir com a recarga? [confirmar]

Depois que o VCUBE-1 inicializar completamente, salve a configuração do VCUBE-2 e recarregue-o.

VCUBE-2#wr

  Configuração de edifício...


  [OK]

VCUBE-2#recarregou

  Prosseguir com a recarga? [confirmar]
6

Verifique se a configuração box a box está funcionando conforme o esperado. Saída relevante é destacada em negrito.

Nós recarregou o VCUBE-2 por último e, de acordo com as considerações do projeto, a plataforma a ser recarregada por último sempre estará em espera.


VCUBE-1# mostra o grupo de aplicativos deredundância todas as Falhas estados Informações do grupo 1:
       Prioridade de tempo de execução: [100] 
               Estado do RG de falhas: Para cima.
                       Nº total de comovers devido a falhas:           0 
                       Nº total de alterações de estado abaixo/para cima devido a falhas: 0 ID do grupo:1 
 Nome do grupo:LocalGateway-HA    Estado administrativo: Nenhum estado 
 operacional agregado de desligamento: Acima de minha função: Função 
 de pares ATIVOS: Presença dos colegas em ESPERA: Sim 
 Peer Comm: Sim, 
 progressão de colega iniciada: Domínio 
 
 Sim RF: estado rf 
         btob-um: Estado 
         DE RF de pares ATIVOS: Modo DE ESPERA 
 
 RG protocolo RG 1 
 ------------------ 
 função: Negociação 
        Ativa: Prioridade 
        habilitada: 100 Estado 
        do protocolo: Estado 
        ativo do Ctrl Intf(s: Up 
        Peer Ativo: Colega         de espera local: endereço 10.1.1.2, prioridade 100, contadors de log intf         Gi3:
                alteração de função para ativa: 1 
                alteração de função para espera: 1 
                desabilita eventos: rg no estado 0, rg desligado 0 
                ctrl intf eventos: até 1, 0, admin_down 0 
                recarregem eventos: solicitação local 0, solicitação de pares 0 Contexto de mídia RG para 
 
 RG 1 
 -------------------------- 
 Estado Ctx: ID do Protocolo Ativo: 1 
        Tipo de mídia: Interface de controle padrão: GigabitEthernet3         Temporizador de Olá atual: 3000 
        Configurado Olá temporizador: 3000, Temporizador de espera: Temporizador de Olá 10000 
        Colegas: 3000, temporizador de espera de pares: 10000 
        Estatísticas:
            Pkts 1509, Bytes 93558, seq 0 HA, número da seqm 1509, perda Pkt 0 Autenticação não configurada 
 
            Falha de autenticação: 0 
            Igual de recarga: TX 0, RX 0 
            Renunciar: TX 0, RX 0 
    Colega autônomo: Presente. Temporizador de espera: 10000 
 Pkts 61, Bytes 2074, seq 0 de HA, seqr número 69, perda Pkt 0 
 
 VCUBE-1 #

VCUBE-2# mostra o grupo de aplicativos deredundância todas as Falhas estados Informações do grupo 1:
       Prioridade de tempo de execução: [100] 
               Estado do RG de falhas: Para cima.
                       Nº total de comovers devido a falhas:           0 
                       Nº total de alterações de estado abaixo/para cima devido a falhas: 0 ID do grupo:1 
 Nome do grupo:LocalGateway-HA    Estado administrativo: Nenhum estado 
 operacional agregado de desligamento: Acima de minha função: Função de colega 
 em ESPERA: Presença de pares ATIVOS: Sim 
 Peer Comm: Sim, 
 progressão de colega iniciada: Domínio 
 
 Sim RF: estado rf 
         btob-um: Estado 
         DE RF de pares ATIVOS: Modo DE ESPERA 
 
 RG protocolo RG 1 
 ------------------ 
 função: Negociação 
        Ativa: Prioridade 
        habilitada: 100 Estado 
        do protocolo: Estado 
        ativo do Ctrl Intf(s: Up         Peer Ativo: endereço 10.1.1.2, prioridade 100, intf Gi3         Standby Peer: Contadors 
        de Registro Local:
                alteração de função para ativa: 1 
                alteração de função para espera: 1 
                desabilita eventos: rg no estado 0, rg desligado 0 
                ctrl intf eventos: até 1, 0, admin_down 0 
                recarregem eventos: solicitação local 0, solicitação de pares 0 Contexto de mídia RG para 
 
 RG 1 
 -------------------------- 
 Estado Ctx: ID do Protocolo Ativo: 1 
        Tipo de mídia: Interface de controle padrão: GigabitEthernet3         Temporizador de Olá atual: 3000 
        Configurado Olá temporizador: 3000, Temporizador de espera: Temporizador de Olá 10000 
        Colegas: 3000, temporizador de espera de pares: 10000 
        Estatísticas:
            Pkts 1509, Bytes 93558, seq 0 HA, número da seqm 1509, perda Pkt 0 Autenticação não configurada 
 
            Falha de autenticação: 0 
            Igual de recarga: TX 0, RX 0 
            Renunciar: TX 0, RX 0 
    Colega autônomo: Presente. Temporizador de espera: 10000 
 Pkts 61, Bytes 2074, seq 0 de HA, seqr número 69, perda Pkt 0 
 
 VCUBE-2 #

Configurar um gateway local em ambos OS CUBEs

No nosso exemplo de configuração, estamos usando as seguintes informações de tronco do Control Hub para construir a configuração do Gateway Local em ambas as plataformas, VCUBE-1 e VCUBE-2. O nome de usuário e a senha para esta configuração são os seguinte:

  • Nome de usuário: Hussain1076_LGU

  • Senha: iOV12MEaZx

1

Certifique-se de que uma chave de configuração seja criada para a senha, com os comandos mostrados abaixo antes de poder ser usado nas credenciais ou na chave compartilhada. As senhas do tipo 6 são criptografadas usando uma codificação AES e essa chave de configuração definida pelo usuário.


LocalGateway#conf 
 localGateway(configuração)# chaveconfig-key-encrypt Password123 LocalGateway(config)# criptografia desenha aes

Aqui está a configuração do Gateway local que será aplicada a ambas as plataformas com base nos parâmetros do Control Hub exibidos acima, salvar e recarregar. As credenciais do SIP Digest do Control Hub são realçadas em negrito.


configurar terminal criptografia pki trustpoint simulaçãoTp revogação-verificação crl sair sip-ua autenticação crl com sinalização de autenticação padrão cvtp cn-san-validate server transport tls tls v1.2 end configurar terminal crki trust dns import clean url configurar terminal serviço de voz voip endereço ip confiável http://www.cisco.com/security/pki/trs/ios_core.p7b lista 
 
 ipv4 x.x.x.x y.y.y.y saia de allow-connections sip para sip media statistics media 
 
 bulk-stats no supplementary-service sip refer no supplementary-service sip refer no 
 
 
 
 supplementary-service sip handle-replaces 
 fax protocol pass-through g711ulaw 
 
 stun stun flowdata agent-id 1 boot-count 4 
 stun flowdata shared-secret 0 Password123! 
  sip g729 anexo g729-Todos os clientes de primeira classe de voz configuram perfis de voz em nível de voz 200 regra 9 Solicitar QUALQUER regra do 
 
 
 
 
 
 
 
 sip-header SIP-Req-URI "sips:(.*)" "sip:\1" regra 10 solicitar QUALQUER sip-header Para modificar " " " " regra 13 resposta QUALQUER<sips:(.*)" "<sip:\1" rule="" 11="" request="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 12="" request="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)><sip:\1;transport=tls>sip-header Para modificar ";otg= hussain1076_lgu >" regra 30 solicitar QUALQUER preferência do<sips:(.*)" "<sip:\1" rule="" 14="" response="" ANY="" sip-header="" From="" modify=""></sip:\1"><sips:(.*)" "<sip:\1" rule="" 15="" response="" ANY="" sip-header="" Contact="" modify=""></sip:\1"><sips:(.*)"
"<sip:\1" rule="" 20="" request="" ANY="" sip-header="" From="" modify="">"
";otg=<sajan index="1" />hussain1076_lgu<sajan index="2" />>"
  rule 30 request ANY sip-header P-Asserted-Identity modify
"sips:(.*)" "sip:\1"


voice class codec 99
  codec preference 1 g711ulaw
  codec preference 2 g711ulaw
  exit

voice class srtp-crypto 200
  crypto 1 AES_CM_128_HMAC_SHA1_80
  exit

voice class stun-usage 200
  stun usage firewall-traversal flowdata
  exit






voice class tenant 200
  registrar <sajan index="3" />codec de sip-header P-Asserted-Identity 
 modifique "sips:(.*)" "sip:\1" codec de classe de voz 99 codec de preferência 1 g711ulaw codec de codec 2 g711ulaw exit voice class srtp-layout 200 de criptografia 1 AES_CM_128_HMAC_SHA1_80 sair da classe de voz stun-usage 200 stun usage firewall-travers os dados de fluxo cionais saem do locatário da classe de voz 200 dns:40462196.esquema cisco-bcld.com expira em 240 taxa de atualização 50 tls número de credenciais de registro Hussain5091_LGU nome de usuário Hussain1076_LGU senha 0 lOV12MEaZx domínio Broadworks autenticação nome de usuário Hussain5091_LGU 
 senha      0 lOV12MEaZ domínio de autenticação BroadWorks Hussain5091_LGU senha  0 lOV12MEaZx domínio 40462196.cisco-bcld.com sem     id sip-server remoto-party dns:40462196.cisco-bcld.com   connection-reutil 
 srtp-proxy 200 session transport 
 tcp tls 
 url sips 
 error-passthru 
 asserted-id pai bind control 
 source-interface GigabitEthernet1 bind media 
 source-interface GigabitEthernet1 sem senha de conteúdo 
 custom-sdp 
 sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com   privacy-policy passthru voice class 00 session transport 
 
 
 
 udp 
 url url 
 error-passthru bind control 
 source-interface GigabitEthernet2 bind media 
 source-interface GigabitEthernet2 sem senha conteúdo 
 personalizado-sdp voice class tenant 
 
 300 bind control 
 source-interface GigabitEthernet2 liga a interface de mídia GigabitEthernet2 sem senha de conteúdo personalizado-sdp classe de voz 
 
 
 
 
 uri 100 sip 
 host ipv4:198.18.13 Classe de voz 3.3 
 
 padrão uri 200 sip 
 dtg=hussain1076.lgu    dial-peer voice 101 voip Descrição 
 outgoing dial-peer 
 para IP PSTN padrão de destino BAD. Protocolo de sessão BAD 
 sipv2 sessão 
 destino ipv4:198.18.133.3 codec de classe de voz 
 99 
 voice-class sip tenant 100 
 dtmf-relay rtp-nte 
 no vad 
 
 dial-peer voice 201 voip Descrição 
 outgoing dial-peer para Webex Calling 
 destination-pattern BAD. Protocolo de sessão BAD sipv2 sessão alvo 
 
 sip-server 
 voice-class codec 99 
 voice-class stun-usage 200 no sip local 
 voice-class sip localhost 
 sip 200 
 dtmf-relay rtp-nte 
 srtp no 
 vad voice class 
 
 
 dpg 100 Incoming 
 WebexCalling(DP)200) para IP PSTN(DP101) dial-peer 101 preferência de 1 classe de voz 
 
 
 dpg 200 descrição ip de entrada 
 PSTN(DP100) para Webex Calling(DP201) dial-peer 201 preferência 1 voz de colega de discagem 
 
 
 
 
 
 
 100 voip descritivo Entrada dial-peer do IP PSTN sessão protocolo sipv2 destino dpg 200 uri de entrada através de 100 codec de classe de voz 99 classe de voz 
 sip 
 
 
 
 
 locatário 300 
 dtmf-relay rtp-nte 
 no 
 
 vad dial-peer voz 200 voip entrada dial-peer do protocolo de sessão Webex Calling destino dpg 100 uri de entrada 200 codec

Para exibir a saída do comando, recarregou o VCUBE-2 seguido peloVCUBE-1, fazendo do VCUBE-1 o CUBE em espera eVCUBE-2 o CUBE ativo
2

A qualquer momento, apenas uma plataforma manterá um registro ativo como o Gateway local com o acesso Webex Calling SBC. Dê uma olhada na saída dos comandos de exibição a seguir.

mostrar grupo de aplicativos de redundância 1

mostrar status do registro sip-ua


VCUBE-1# mostra o grupo de aplicativos de redundância 1 ID do grupo:1 Nome do 
 grupo:LocalGateway-HA 
 
 Estado administrativo: Sem estado 
 operacional agregado de desligamento: Up My Role: Função de colega em espera: Presença 
 de pares ATIVOS: Sim 
 Peer Comm: Sim, 
 progressão de colega iniciada: Domínio 
 
 Sim RF: estado rf 
         btob-um: Estado DE RF EM TEMPO DE 
         ESPERA: VCUBE ATIVO-1#mostrar sip-ua status de registro VCUBE-1 #

VCUBE-2# mostra o grupo de aplicativos de redundância 1 ID do grupo:1 Nome do 
 grupo:LocalGateway-HA 
 
 Estado administrativo: Sem estado 
 operacional agregado de desligamento: Up My Role: Função de pares ATIVOS: STATUS 
 Peer Presence: Sim 
 Peer Comm: Sim, 
 progressão de colega iniciada: Domínio 
 
 Sim RF: estado rf 
         btob-um: Estado 
         DE RF de pares ATIVOS: MODO DE ESPERA 
 
 VCUBE-2#mostrar o status de registro sip-ua  Locatário: 200 
 --------------------Registrar-Índice 1 --------------------- Linha pares 
 expira(seg) reg re disponível P-Associ-URI 
 ================================= ========== ========== ======== =========== 
 Hussain5091_LGU -1 48 sim normal 
 VCUBE-2 #

A partir da saída acima, você pode ver que VCUBE-2 é a ativa LGW mantendo o registro com acesso Webex Calling SBC, enquanto a saída do "mostrar status de registro sip-ua" está em branco no VCUBE-1
3

Agora habilita as seguintes depurações no VCUBE-1


VCUBE-1# debugccsip non-call SIP Out-of-Dialog está habilitado 
 VCUBE-1# debug ccsip info sip Call info tracing está habilitado VCUBE-1#depurar mensagem ccsip
4

Simule o failover em emissão do seguinte comando no LGW ativo, VCUBE-2 neste caso.


VCUBE-2#redundância aplicativo recarregou o grupo 1 auto-

Alternar do ATIVO para o LGW EM ESPERA ocorre no seguinte cenário, além do CLI listado acima

  • Quando o roteador ATIVO recarregar

  • Quando o roteador ATIVO reativar os ciclos de energia

  • Quando qualquer interface configurada RG do roteador ATIVO é desligado para o qual o rastreamento está habilitado
5

Verifique se o VCUBE-1 se registrou com Webex Calling acesso A SBC. VCUBE-2 já seria recarregado.


VCUBE-1# mostrao status do registro sip-ua 
 
 Locatário: 200 
 --------------------Registrar-Índice 1 --------------------- Linha pares 
 expira(seg) reg remapeou P-Associ-URI 
 =============================== ========== ========== ======== ============ Hussain5091_LGU -1 56 sim VCUBE-1 normal #

VCUBE-1 agora é o LGW ativo.
6

Veja o relevante registro de depuração no VCUBE-1 enviando um SIP REGISTER para Webex Calling VIA IP virtual e recebendo um 200 OK.


VCUBE-1#mostrar log 9 de 
 
 janeiro 18:37:24.769: %RG_MEDIA-3-TEMPORIZADOREXPIR: ID RG 1 Olá Hora expirada.
9 de janeiro 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: Alteração da função RG id 1 de Modo de Espera para Ativo 9 de 
 Janeiro 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, de STANDBY_HOT ao estado ATIVO.
9 de janeiro 18:37:24.783: -1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Notificar notificar o evento de função ativa 
 
 9 de janeiro 18:37:25.758: -1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Enviado:
REGISTRAR sip: 40462196.cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 
 De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Para: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Data: Qui, 09 de janeiro de 2020 18:37:24 GMT 
 Chamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Agente-Usuário: Encaminhamentos máximos do Cisco-SIPGateway/IOS-16.12.02: 70 
 Timestamp: 1578595044 
 CSeq: 2 REGISTRAR 
 CONTATO: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expira: 240 
 Suportado: Comprimento 
 do conteúdo do caminho: 0

9 de janeiro 18:37:25.995: -1/00000000000/SIP/Msg/ccsipDisplayMsg:
Recebido:
SIP/2.0 401 não autorizado através de: SIP/2.0/TLS 198.18.1.228:5061;recebido=173.38.218.1;branch=z9hG4bK0374;rport=4742 
 De: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Para: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 
 Data: Qui, 09 de janeiro de 2020 18:37:24 GMT 
 Chamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Timestamp: 1578595044 
 CSeq: 2 REGISTRE 
 WWW-Autenticar; Domínio DIGEST="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algoritmo=MD5 Comprimento de 
 conteúdo: 0

9 de janeiro 18:37:26.000: -1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Enviado:
REGISTRAR sip:40462196.cisco-bcld.com:5061 SIP/2.0 via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC A partir 
 de: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Para: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>
Data: Qui, 09 de janeiro de 2020 18:37:25 GMT 
 Chamada-ID: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Usuário-Agente:Cisco-SIPGateway/IOS-16.12.02 
 Max-Forwards: 70 
 Timestamp: 1578595045 
 CSeq: 3 REGISTRAR 
 CONTATO: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>
Expira: 240 
 Suportado: Autorização 
 do caminho: Nome de usuário de resumo="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",resposta="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algoritmo=MD5,=0000001 Comprimento 
 de conteúdo: 0

9 de janeiro 18:37:26.190: 1/0000000000/SIP/Msg/ccsipDisplayMsg:

Recebido:
SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;recebido=173.38.218.1;branch=z9hG4bK16DC;rport=4742 
 de: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 
 Para: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 ID da 
 chamada: FFFFFFFFEA0684EF-324511EA-FFFFFF800281CD-FFFFFFFFB5F93B97 
 Timestamp: 1578595045 
 CSeq: 3 REGISTRAR 
 CONTATO: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 
 Allow-Events: chamada-informações,diálogo-diálogo,mensagem-resumo,como recurso-evento,x-broadworks-hoteling,x-broadworks-call-center-status,conferência 
 Conteúdo-Comprimento: 0