Voz e comunicações unificadas : Cisco Unified Communications Manager (CallManager)

Anúncio da inicial do piloto da caça CUCM não ouvido por calleres externos

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como identificar a peça defeituosa quando os calleres externos não ouvem o anúncio inicial (quando chamam um piloto da caça com o disponível permitido enfileiramento de chamada) da liberação do gerente das comunicações unificadas de Cisco 9.0(1).

Contribuído por Kristof Van Coillie, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

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

  • Característica do enfileiramento de chamada
  • Recursos de mídia

Componentes Utilizados

Este documento não é restringido às versões de hardware específicas. Para o software é aplicável à liberação do gerente das comunicações unificadas de Cisco 9.0(1) e mais alto.

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.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter informações sobre convenções de documentos.

Informações de Apoio

A liberação do gerente das comunicações unificadas de Cisco 9.0(1) fornece o enfileiramento de chamada aos usuários de modo que os chamadores possam ser realizados em uma fila até que os membros da caça estejam disponíveis para responder aos atendimentos. Os chamadores em uma fila recebem um anúncio inicial do cumprimento, seguido pela música ou por um tom na posse.

Problema

Quando um atendimento estiver colocado ao piloto da caça, e o anúncio inicial não estiver ouvido por calleres externos (mas por ele está ouvido ao chamar o piloto da caça está chamado de um telefone IP interno), este está causado tipicamente pelo provedor de serviços que não corta com os media antes que o atendimento esteja conectado.

Solução

A fim confirmar a edição, você precisa de verificar:

  1. Envie o Progress Indicator = 8 ao fornecedor.
  2. O anúncio inicial está sendo fluído. Tome uma captação da modulação de código de pulso (PCM).

A fim verificar o Progress Indicator = 8 ao fornecedor, enabe que o q931 de ISDN debuga no gateway. Quando você tem um sistema ocupado, siga os melhores prática recolher debuga como descrito neste documento: Como recolha corretamente e com segurança debuga em um IOS Router.

Você deve ver o Progress Indicator como segue:

*May 18 08:25:22.169: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8  callref = 0x00BF
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Progress Ind i = 0x8183 - Origination address is non-ISDN
        Calling Party Number i = 0x0180, '6611112'
                Plan:ISDN, Type:Unknown
        Called Party Number i = 0x81, '2000'
                Plan:ISDN, Type:Unknown
*May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x80BF
        Channel ID i = 0xA98381
                Exclusive, Channel 1
*May 18 08:25:22.197: ISDN Se0/1/0:15 Q931: TX -> PROGRESS pd = 8  callref = 0x80BF
        Progress Ind i = 0x8188 - In-band info or appropriate now available

## Initial announcement being played ##

*May 18 08:25:27.941: ISDN Se0/1/0:15 Q931: TX -> ALERTING pd = 8  callref = 0x80BF
        Progress Ind i = 0x8088 - In-band info or appropriate now available

## The call is ringing at agent phone ##

*May 18 08:25:30.309: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8  callref = 0x80BF

## The call is connected with the agent ##

*May 18 08:25:30.313: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x00BF

## Call is ended by calling party ##

*May 18 08:25:34.101: ISDN Se0/1/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x00BF
        Cause i = 0x8290 - Normal call clearing
*May 18 08:25:34.289: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x80BF
*May 18 08:25:34.293: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x00BF

No exemplo acima, você vê que o anúncio inicial está sendo jogado por aproximadamente cinco segundos. Em seguida, os anéis do atendimento no agente telefonam (à ALERTA) e finalmente você vê o mensagem CONNECT quando o agente responde ao atendimento.

A fim verificar que você está fluindo o anúncio, você deve tomar uma captação PCM, documentada em: Cisco IOS, telefone, pacote UCM e CUC, e de captações PCM referência de comandos. Considere o uso de um anúncio mais longo se você enfrenta desafios para recolher a tempo a captação pcm.

Se ambos foram verificados com sucesso, a edição está causada pelo provedor de serviços e não cortando com os media antes que o atendimento esteja conectado. Este problema deve ser fixado pelo provedor de serviços. Se qualquer um dos artigos acima falta, a situação deve ser mais detalhada investigado no gerente das comunicações unificadas de Cisco ou no lado do gateway.

Advertências relacionadas:

A identificação de bug Cisco CSCuh15872 CUCM9 que o enfileiramento de chamada nativo deve conectar chama o announcment

O enfileiramento de chamada nativo da identificação de bug Cisco CSCug87543 CUCM não trabalha se o ingresso é H323 jejua começo

Informações Relacionadas



Document ID: 116230