Pesquise defeitos etapas para seguir quando o CUBO não é descoberto como o elemento da beira no PCA

Introdução

Este documento descreve as etapas a ser seguidas para pesquisar defeitos quando o Cisco Unified Border Element (CUBO) não é descoberto como o elemento da beira no acreditação principal da Colaboração (PCA).

Pré-requisitos

Requisitos

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

• PCA
• Gerente das comunicações unificadas de Cisco (CUCM)
• CUBO

Componentes Utilizados

A informação neste documento é baseada no acreditação principal da Colaboração.

  

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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Etapas a ser seguidas se o CUBO não é descoberto como o elemento da beira no PCA

Para que um CUBO seja identificado como o elemento da beira no PCA:

1. a. Desenvolvimento NON-CUCM: Estas circunstâncias devem ser satisfeitas:

Condição-1: O modelo do dispositivo deve estar na lista de plataformas suportadas (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - tabela 2.

Circunstância 2: O SIP-UA-MIB deve retornar o valor a não ser o noSuchObject/noSuchInstance para SipCfgPeerTable.

1. b. Desenvolvimento CUCM: Estas circunstâncias devem ser satisfeitas:

Condição-1: O modelo do dispositivo deve estar na lista de plataformas suportadas (http://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-border-element/data-sheet-c78-729692.html?cachemode=refresh,) - tabela 2.

Circunstância 2: O SIP-UA-MIB deve retornar o valor a não ser o noSuchObject/noSuchInstance para SipCfgPeerTable.

Circunstância 3: O IP address do dispositivo deve ser associado com o tronco do SORVO de um do CUCM.

Para que um dispositivo esteja identificado como o CUBO SP, deve primeiramente ser identificado enquanto o CUBO e devem responder a CISCO_SESS_BORDER_CTRLR_CALL_STATS_MIB.csbSIPMthdCurrentStatsAdjName (1.3.6.1.4.1.9.9.757.1.3.1.1)

Se estas circunstâncias são estadas conformes e ainda o PCA não identifica o dispositivo como o elemento da beira, a seguir verifique se a configuração em CUCM e em dispositivo.

O Cubo-lado da integração do CUCM-à-CUBO

Quando você estabelece primeiramente um CUBO, você deve permitir o roteador a fim distribuir atendimentos como um CUBO. Esta imagem mostra uma configuração de VoIP básica do serviço de voz em um CUBO:

Estão aqui alguns pontos importantes sobre esta configuração:

• A primeira linha da configuração é o beira-elemento do modo, que permite o CUBO em um roteador. Alguns dispositivos não têm esta configuração quando se operam como um CUBO.
• as Permitir-conexões sorvem para sorver permitem o CUBO de aceitar atendimentos do Session Initiation Protocol (SIP) e de distribui-los enquanto o SORVO chama. Há umas opções para H323 também.
• O protocolo t38 do fax é uma configuração padrão para o Roteadores ISR G2. Não é precisado para a configuração do CUBO.
• a Cedo-oferta forçada permite que o CUBO distribua atendimentos em uma oferta atrasada para oferecer cedo a encenação. Quase todos os fornecedores exigem atendimentos adiantados do SORVO da oferta. Recomenda-se realmente enviar a oferta adiantada de CUCM a fim evitar media adiantados corte-através das edições.
• o passthru da Midcall-sinalização é somente para atendimentos do Sorvo-à-SORVO. Exige-se para que alguns serviços suplementares trabalhem.
• O G729 annexb-todo é ótimo nos casos onde o CUBO negocia com os fornecedores que não seguem o formato RFC para o G729R8 e os codecs G729br8.

Configuração de dial peer no CUBO

O dial peers no CUBO é como o outro dial peers em Cisco IOS gateway. A diferença é que a rota dos atendimentos de um VoIP dial-peer a um outro VoIP dial-peer.

Observe que há dois dial peers aqui: entrante e que parte. O CUBO combina sempre dois dial peers. Os dial peer entrante são da perspectiva do CUBO, do CUCM ou do fornecedor do SORVO. Os dial peer de saída são enviados para o CUCM ou ao fornecedor do SORVO.

ICisco recomenda que você executa a maioria da Manipulação de dígitos em CUCM com os dígitos significativos, a máscara externo do número de telefone, e as traduções.

Refira compreendendo os dial peer de entrada e de saída que combinam no artigo das plataformas IOS para obter mais informações sobre do dial peers.

A Manipulação de dígitos pode ser executada no CUBO, a mesma maneira que é executado no Gateways de voz do Cisco IOS. Refira a tradução do número usando o artigo dos perfis da tradução da Voz para mais informação.

Endereçamento de IP básico

O endereçamento de IP no CUBO é realizado a mesma maneira que em outros dispositivos IOS Cisco, mas usa a tabela de roteamento a fim determinar de que relação as fontes do CUBO SORVEM o tráfego. O comando a.b.c.d da rota da mostra IP fornece a informação sobre a relação que o CUBO usa o tráfego do SORVO da fonte. Isto é importante quando os atendimentos estão enviados a CUCM e quando os atendimentos estão enviados a um fornecedor do SORVO. As rotas estáticas puderam ser precisadas a fim fazer este trabalho.

Em alguns casos, você pôde ter que ligar o SORVO a uma interface particular, tal como uma interface de loopback no CUBO. O emperramento do SORVO pode causar efeitos secundários, como quando o CUBO não escuta o tráfego do SORVO em uma interface particular. Cisco recomenda que você não usa emperramentos e deixa a tabela de roteamento decidir, mas esta não é sempre possível. Você pode aplicar emperramentos do SORVO sob o serviço de voz VoIP > SORVO, ou no dial peers individual. Os emperramentos do SORVO são explicados mais no artigo de características configurando do ligamento do SORVO.

Codecs da Voz-classe no CUBO

os codecs da Voz-classe estão usados para o CUBO a fim oferecer codecs múltiplos quando os atendimentos usam um VoIP dial-peer particular. Este é o mesmo como era em um gateway de voz do Cisco IOS, mas quando é um CUBO, os codecs são filtrados de um pé da chamada VoIP ao outro. Usa os codecs que estão disponíveis no dial peer entrante e no dial peer de saída. Os codecs que combinam ambos são enviados a ofertas. Quando o CUBO receber uma mensagem do SORVO com protocolo session description (SDP), igualmente combina este contra os codecs da Voz-classe. Isto permite que o CUBO filtre os codecs baseados no que é recebido da mensagem do SORVO com SDP, do dial peer de entrada, e do dial peer de saída. O outro o agente de usuário do SORVO (UA) responde então aos codecs oferecidos.

O codec de classe de voz na imagem anterior contém três codecs, G729R8s, g711ulaw, ou g711alaw. A imagem mostra-os na ordem em que o Cisco IOS gateway dá a prioridade a como os codecs são oferecidos à ponta oposta.  os codecs da Voz-classe são aplicados ao dial peers.

O CUCM-lado da integração do CUCM-à-CUBO

1. A fim adicionar o tronco à configuração CUCM, navegue a este lugar:
   
   

2. Seleto adicionar novo e continue estabelecer como mostrado o tronco do Session Initiation Protocol (SIP) aqui:
   
   

3. Dentro da página da configuração de tronco, recorde selecionar o pool de dispositivos apropriado que permite os atendimentos de entrada ao server particular CUCM que aceita atendimentos.
   
   

Uma vez que o tronco é criado, assegure-se de que as rotas padrão o alcancem corretamente com uma rota padrão do SORVO ou uma instalação da lista/grupo de rotas da rota.

O cabeçalho de desvio de reorientação pode ser tiquetaqueado para de entrada ou chamadas externas.

Quando os números externos são encaminhados na rede voip, o SORVO convida mensagens vem com informação retransmitida da diversão em CUCM. Mostra a chamada originada da origem. Por exemplo, se um fluxo de chamadas é integrado com UC e entra no correio de voz, o UC usa a fonte inicial da diversão (número encaminhado externo) como a caixa postal de destino. Assim é possível que poderiam obter a saudação inicial do padrão em vez da caixa de correio de assinantes como esperado. Depende do fluxo de chamadas e das exigências de sua topologia se este está indo ser exigido para a configuração.

4. O perfil do SORVO para a oferta adiantada é precisado frequentemente quando você conecta o CUBO a um fornecedor. Se o tronco conecta a um outro dispositivo Cisco, a seguir você não pôde querer selecionar a inserção do protocolo de transporte dos media (MTP), com base nos dispositivos de extremidade oposta. Esta imagem mostra o lugar do perfil do SORVO e onde selecionar a caixa para a oferta adiantada. 

A oferta adiantada ajuda frequentemente a resolver as edições adiantadas dos media que elevaram quando você integra o server e o CUBO CUCM a outros produtos de terceira parte. Igualmente recomenda-se dentro do projeto de rede da referência da solução (SRND).

Se o perfil está indo ser alterado, é sempre o melhor criar um perfil novo para usar-se em vez do perfil padrão. 

Nota: Esta caixa de seleção é usada quando os utilizadores finais não querem ter um MTP usado em cada atendimento.

5. Pôde ser necessário mudar do TCP/UDP para o protocolo dentro do perfil de segurança do SORVO baseado no fluxo de chamadas. A fim fazer esta mudança, navegue PARA SORVER perfis de segurança do tronco > fixam não o perfil do tronco do SORVO:

Os atendimentos falharão, e os traços CUBE/CUCM são exigidos a fim compreender o que acontece na altura da falha, mas esta característica pode ser alterada a fim confirmar que não é a causa do problema. Contudo, uma vez que este é alterado, você deve restaurar/reinício o tronco a fim fazer a mudança ocorrer.

6. Em algumas circunstâncias, a máscara externo do telefone na configuração telefônica pôde precisar de ser adicionado para que o atendimento continue, porque alguns telcos não permitem que o atendimento continue sem a máscara prevista. A fim fazer esta alteração, vá à página de configuração do número de diretório (DN) do telefone da chamada originada, fazem a mudança necessária para a caixa, e a restauração/reinício o telefone após as mudanças salvar.
   
   

Uma vez que esta configuração é feita em CUCM, inicie a descoberta do conjunto no PCA.

O dispositivo será descoberto agora como o elemento da beira no PCA.