Voz e comunicações unificadas : Cisco Unified Border Element

MMoH com a operação do CUBO, configuração, e pesquisa defeitos o guia

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 a operação, a configuração, e a informação de Troubleshooting para a Música-em-posse do Multicast (MMoH) através do Cisco Unified Border Element (CUBO).

Embora o foco deste documento seja Música-em-posse do Multicast (MoH), uma parte substancial é devotada a descrever como MoH trabalha geralmente. Esta informação adicional ajuda a construção um base-conhecimento para o novato a fim reconhecer e apreciar melhor as edições que são específicas a MMoH.

Nota: Quando os princípios forem mesmos, Cisco unificou o fornecedor que do Elemento-serviço da beira a edição (CUBE-SP) não cai no âmbito deste documento, nem CUBA o uso nos ambientes que não envolvem o gerente das comunicações unificadas de Cisco (CUCM).

Contribuído por Bakthavatsal Muralidharan, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos 

Não existem requisitos específicos para este documento.

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

Background

Nota: À excecpção de um par encenações que são ilustradas para H.323, a sinalização do Session Initiation Protocol (SIP) é usada durante todo a maioria deste documento.

Vista geral de MoH

MoH é jogado sempre que um chamador é de (em) espera colocado. a Atendimento-posse é iniciada pelo usuário ou pela rede quando um processo do serviço suplementar é executado, como o atendimento para a frente ou a transferência. O anterior é referido como posse, USER-posse, ou posse USER-iniciada do usuário. O último é referido como posse, rede-posse, ou posse rede-iniciada da rede.

Está aqui uma revisão de como MoH trabalha com os gateways da multiplexação de divisão de tempo (TDM). Esta imagem ilustra os componentes e as conexões envolvidos em uma encenação da atendimento-posse:

 

A fim colocar um atendimento de (em) espera, um processo em duas etapas é precisado. Esta imagem ilustra as duas etapas envolvidas:

 

Dica: Recorde este processo em duas etapas quando você tenta classificar com a configuração MOH e pesquisar defeitos edições.

Fontes de MoH

O usuário que coloca um atendimento de (em) espera é referido como o suporte, e o usuário que é de (em) espera colocado (e ouve MoH) é referido como o holdee. Cada lado decide determinados aspectos da música que é jogada.

 

A fonte da música é determinada pelo suporte. A determinação segue esta hierarquia:

  1. A fonte da música configurada no Domain Name (DN)
  2. A fonte da música configurada no dispositivo
  3. A fonte da música no perfil de dispositivo (fonte da música da USER-posse somente)
  4. A fonte da música no nível global (parâmetro de serviço, ou no exemplo)

Há dois grupos de fontes da música, chamados USER-posse e rede-posse. Sempre que a referência é feita à fonte da música, poderia significar uma fonte da USER-posse ou da música da rede-posse.

Valores-limite de MoH

Para finalidades de MoH, o valor-limite no lado CUCM é o server de MoH. Isto é importante de compreender porque a determinação do codec (baseada na configuração do codec da inter-região) é baseada sobre:

  • A região de servidor de MoH
  • A região do tronco/gateway

O recommedation geral é atribuir ao server de MoH uma região dedicada, de modo que o codec da inter-região entre essa região e todas regiões restantes seja g.711 (ou o outro codec que você quer fluir para fora para MoH).

Da perspectiva CUCM, os valores-limite envolvidos no atendimento não são os dois telefones, mas um pouco:

  • O telefone IP registrado a CUCM
  • O gateway/CUBE

Assim, CUCM trata o tronco que aponta ao gateway/CUBE na pergunta como o valor-limite, e olha nos recursos associados com ele a fim determinar como render o córrego da música.

Protocolo de VoIP de MoH

MoH, por definição, é uma conversação do áudio de sentido único. Como se sinaliza depende do protocolo de VoIP usado. Por exemplo, no SORVO, isto é transportado através do atributo do sentido. Em H.323, o CUCM especifica 00000000 como o endereço de rede e 0 como a porta (mais tsapIdentifier) do server de MoH na mensagem aberta Ack do canal lógico H.245 (OLCAck).

Nota: Para MMoH, CUCM envia o endereço de multicast (239.1.1.1, por exemplo) como o endereço de rede.

Nos fluxos de chamadas que envolvem o CUBO, o CUCM não tem nenhum conhecimento sobre o trecho de chamada entre o CUBO e o provedor de serviços da telefonia pelo Internet (ITSP). O CUCM é estado relacionado somente com o trecho de chamada entre o telefone IP e o tronco do SORVO (que conduzem PARA CUBAR).

O processo de sinalização para MoH é similar à sinalização para uma conversação nova, com espaço reduzido. No SORVO, por exemplo, a conversação ocorre dentro do contexto do diálogo que já existe .[1]

Desabilite o fluxo de mídia

A primeira etapa no processo em duas etapas previamente mencionado é desabilitar o fluxo de mídia.

Esta imagem ilustra como o fluxo de mídia é desabilitado no SORVO:

 

As aplicações do SORVO variam se um ou ambo o atributo (? a=? e? C=IN?) são usados a fim indicar que o fluxo de mídia está desabilitado.

Esta imagem ilustra como o fluxo de mídia é desabilitado em H.323:

  

Conecte a MoH

O segundo passo no processo em duas etapas previamente mencionado é conectar a MoH. Uma vez que o fluxo de áudio é desabilitado, CUCM sinaliza a conversação de sentido único de MoH que faz com que o holdee escute a fonte de MoH.

Como parte deste processo, CUCM leva em consideração as capacidades dos media do holdee e da lista do grupo dos recursos de mídia (MRGL) associados com o tronco antes que determine os parâmetros para fluir. Em conformidade, sinalizar para esta é sempre a oferta atrasada (FAÇA) [2] (no SORVO).

O número real de CONVIDA transações varia. Por exemplo, CUCM conecta o holdee a MoH com o apenas um CONVIDA a transação. Alternativamente, CONVIDE é usado a fim recolher as capacidades dos media do holdee, e um EO subsequente CONVIDA é usado a fim conectar realmente o holdee a MoH.

Esta imagem ilustra a transação para o SORVO:

Esta imagem ilustra a transação para H.323:

Esta imagem ilustra a sequência do mensagem de sinalização em um ambiente de colaboração (quando um lado do CUBO é SORVO e o outro lado H.323, por exemplo):

 

Quando os recursos de mídia forem usados em um atendimento

Protetor dos recursos de mídia (ponto de MediaTermination (MTP)/transcodificadores) o trecho de chamada do provedor de serviços a Cubo-à-TI (ITSP) geralmente. Quando uns recursos de mídia são usados em um atendimento através do CUBO, sinalizar para MoH envolve na maior parte mensagens do protocolo skinny client control (SCCP) entre CUCM e os recursos de mídia. Observe que é os recursos de mídia que são postos sobre a posse, não o tronco do CUBO. Depois que o MTP/Transcoder está sinalizado para escutar MoH (SORVO presumido), CUCM envia um mensagem de atualização do SORVO PARA CUBAR. Isto atualiza o parâmetro de ramo, que identifica a transação nova (a conversação MOH).

Recomece o atendimento

O processo do resumo é similar ao processo da posse, salvo que a ordem é invertida:

  1. O fluxo de áudio atual é desabilitado.
  2. Outros re-CONVIDAM são enviados a fim reconectar o holdee ao telefone que colocou o atendimento de (em) espera. 

Atributo SDP

Os X-Cisco-media: o atributo do umoh no protocolo session description (SDP) foi introduzido a fim simplificar MoH que sinaliza sobre os troncos inter-grânulo (ICT) [3]. Com interoperação entre os valores-limite que usam protocolos diferentes, CUCM executa frequentemente a sinalização inábil e intermediária que é NON-intuitiva. A fim evitar a adivinhação, e fazer a sinalização contexto-explícita, um atributo proprietário SDP, X-Cisco-media Nomeados, é usado.

Com versões 8.5 e mais recente CUCM, MoH pode [4] ser sinalizado com este grupo do atributo à música do unicast na posse (UMoH) ou ao MMoH, que removem a confiança em um valor de porta falsificado para indicar uma encenação de MoH ao guardar-partido.

Nota: Isto não afeta a sinalização de MoH com CUBO.

MoH no CUBO

Com CUBO, o processo básico permanece o mesmo; contudo, é importante considerar que o CUBO [5] não transcode MoH até a versão 15.3T do½ do¿Â do Cisco IOSïÂ. Isto significa que você deve ser cuidadoso com os fatores que influenciam a seleção do codec no pé do CUCM-à-CUBO de modo que um transcodificador não seja precisado.

Nota: O transcodificador provido aqui é introduzido pelo CUBO (ao contrário de CUCM). Tanto quanto CUCM, o CUBO é o destino, e não envolve nenhum transcodificador no trajeto do Server-à-CUBO MOH.

Considerações do codec

Geralmente, diversos fatores afetam o codec usado no pé do CUCM-à-CUBO, mas estas considerações aplicam-se para MoH:

  • MoH não pode ser transcoded. [5]
  • MoH soa bom somente com G.711.

Nota: Este assunto é fora do âmbito deste documento porque muitos bons documentos já existem em considerações do codec, e seria redundante cobri-lo aqui.

MMoH

Nota: A maioria da informação descrita neste documento é até aqui relevante se o MoH está fluído com unicast ou pacotes do IP de transmissão múltipla.

MMoH conserva recursos de sistema e largura de banda. O Multicast permite que os usuários múltiplos usem o mesmo córrego da fonte de áudio a fim fornecer a música de (em) espera. MMoH é desejável em toda a rede corporativa onde as economias da largura de banda são importantes.

Estão aqui alguns interesses e edições quando o CUBO passa MMoH sobre o Internet ao ITSP:

  • Alcance do tráfego multicast - Cisco usa a escala 239.0.0.0 a 239.255.255.255 para a música do Multicast. Esta escala é sabida como endereços administrativamente no escopo. Este bloco é considerado privado, assim que significa que está usado por redes de empreendimento, e deve nunca ser enviado fora da empresa. Os roteadores limítrofes são configurados geralmente em conformidade.
  • Multicast sobre o VPN - À revelia, a Segurança IP não apoia MMoH.

Isto é como o CUBO apoia MMoH:

  1. O CUBO recebe os pacotes de MMoH do server de MoH.
  2. Converte os pacotes em pacotes IP do unicast.
  3. CUBO para a frente os pacotes ao ITSP.

Manipulação do atributo do sentido do SORVO

Como descrito no RFC 3264:

“Se uma Descrição da Sessão contém um fluxo de mídia do Multicast que esteja alistado como recebem (envie) somente, significa que os participantes, incluindo o offerer e o respondente, podem somente receber (para enviar) nesse córrego. Isto difere da opinião do unicast, onde o directionality refere o fluxo dos media entre o offerer e o respondente. Além desse esclarecimento, a semântica de um fluxo de transmissão múltipla oferecido é exatamente como descrito no RFC 2327 [1]"

Em conformidade, quando CUCM envia um re-CONVITE com um endereço IP multicast, ajusta o atributo do sentido a recvonly; contudo, desde que o CUBO converte os pacotes de transmissão múltipla em pacotes do unicast, deve ajustar o atributo do sentido a sendonly no pé com ITSP.

Esta imagem ilustra a lógica:

  

Manipulação do endereço

No DO[6] re-CONVIDE enviado a fim conectar o chamador ITSP à fonte de MoH, CUBO envia seu próprio endereço IP de Um ou Mais Servidores Cisco ICM NT no campo do SORVO SDP C=IN. Este é um endereço de unicast.

Esta imagem fornece a vista de ponta a ponta:

 

Nota: O CUBO deve executar a versão do Cisco IOS a fim apoiar 15.2(2)T ou mais tarde MMoH. 

Córrego de um flash

Com gateways TDM, as economias adicionais da largura de banda de WAN são realizadas fluindo o direito da música do Multicast do gateway. Assim, se o server de MoH está nas matrizes, e o gateway está em um filial remota através de uma conexão de WAN, o tráfego multicast que leva MoH não tem que atravessar WAN (das matrizes ao ramo) e usar a largura de banda de WAN valiosa.

O CUBO é um dispositivo do Lado de truncamento que não seja capaz de fluir MMoH que é originado do flash local ou através de toda a relação do analógico TDM. É ainda possível realizar a largura de banda de WAN. Isto é realizado com uso de um outro roteador ativado por voz no filial remota como a fonte do córrego de MMoH. Este roteador flui MMoH do flash. O CUBO pode então ser sinalizado a fim receber aqueles pacotes, convertê-los, e passá-los sobre como pacotes do unicast.

Córrego de um alimento vivo

A fim fluir de um alimento vivo, um outro roteador deve ser configurado porque o CUBO não é um dispositivo da linha lateral, como discutido na seção anterior.

Configurar MMoH

Esta seção descreve como configurar MMoH no Switches do CUBO, CUCM, e L3-capable.


Configurar MMoH no CUBO

Use estes comandos a fim configurar MMoH no CUBO:

ccm-manager music-on-hold
ip multicast-routing

Configurar MMoH em CUCM

Siga estas etapas a fim configurar MMoH em CUCM:

  1. Permita a potencialidade de transmissão múltipla na fonte de MoH, no server de MoH, e no grupo dos recursos de mídia (MRG).
  2. Atribua um MRGL ao tronco com o MRG configurado em etapa 1.
  3. Configurar o codec em parâmetros defluência dos serviços de aplicativo IP.

Nota: Refira a música na seção da posse do Cisco Unified Communications System 9.0 SRND - artigo dos recursos de mídia para etapas da configuração detalhada.

Configurar MMoH no Switches L3-Capable

Use estes comandos a fim configurar MMoH no Switches L3-capable:

ip routing
ip multicast-routing

Quando o MTP for usado em um atendimento

Os MTP não apoiam a música do Multicast. O holdee recebe somente dead-air.[7]

Nota: Os transcodificadores são MTP igualmente.

Considerações de desempenho

Todos os pacotes MMOH são processo comutado no Cisco IOS. Esta é muito bem para disposições pequenas, mas tem um impacto significativo no desempenho do CUBO para as grandes instalações.

Restrições

Está aqui uma lista de limitações com o uso de MMoH:

  • O CUBO deve estar a versão do Cisco IOS em 15.2(2)T ou em mais tarde.
  • MMoH não é apoiado em AS54xx.
  • MMoH não é apoiado no ISR-G1s (28xx, o 38xx Series)
  • Esteja ciente dos codecs que são apoiados.

Troubleshooting

Use esta seção a fim pesquisar defeitos MMoH. 

comandos show e debug

Estão aqui uma lista de comandos show and debug, e seus significados:

  • Mostre a música do CCM-gerente - As ajudas confirmam que o CUBO sabe onde escutar pacotes da música do Multicast, e também se os recebe.
    R1#show ccm-manager music
    Current active multicast sessions : 1

     Multicast       RTP port   Packets       Call   Codec    Incoming

     Address         number     in/out        id              Interface

    ===================================================================

    239.176.201.1     16384   956/956          237  g711ulaw  Se0/1/0 
  • Mostre membros do igmp IP - Usado a fim verificar se o CUBO se juntou com sucesso ao grupo de transmissão múltipla quando sinalizado para escutar a música do Multicast.

  • Estes três comandos são usados a fim verificar o codec, o endereço IP de Um ou Mais Servidores Cisco ICM NT, e os números de porta negociados dos valores-limite:
    Show call active voice compact
    Show voip rtp conn
    Show sip calls
    Estão aqui umas saídas de exemplo do primeiro comando:
    R1#show call active voice compact

     <callID>  A/O FAX T<sec> Codec       type        Peer Address       IP R<ip>:<udp>

    Total call-legs: 2

           236 ANS     T53    g711ulaw    VOIP        P1003    239.176.201.1:16384

           237 ORG     T53    g711ulaw    VOIP        P919789362814    200.200.200.2:17808
  • Mostre a edição do resumo da voz ativa do atendimento este comando quando o atendimento é de (em) espera a fim verificar se o rx/tx conta o incremento.
    0    : 236 29262010ms.1 (*22:34:23.659 UTC Fri May 10 2013)
     +4190 pid:1000 Answer 1003 connected
     dur 00:01:38 tx:919/147040 rx:918/146880 dscp:0 media:0 audio tos:0xB8 video tos:0x0
     IP 239.176.201.1:16384 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
     g711ulaw TextRelay: off Transcoded: No
     media inactive detected:n media contrl rcvd:n/a timestamp:n/a
     long duration call detected:n long duration call duration:n/a timestamp:n/a

    0    : 237 29262010ms.2 (*22:34:23.659 UTC Fri May 10 2013)
     +4190 pid:2000 Originate 919789362814 connected
     dur 00:01:38 tx:8910/1425600 rx:919/147040 dscp:0 media:0 audio tos:0xB8 video tos:0x0
     IP 200.200.200.2:17808 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms
     g711ulaw TextRelay: off Transcoded: No
     media inactive detected:n media contrl rcvd:n/a timestamp:n/a
     long duration call detected:n long duration call duration:n/a timestamp:n/a
  • Mostre a classe de “dispositivo MOH da pergunta perf Cisco” - este comando CLI CUCM está usado a fim verificar rapidamente se uns recursos MOH são atribuídos, e que tipo (unicast ou Multicast). Este comando não é muito útil quando você tem a nenhum-posse das chamadas múltiplas, como a mudança das contagens dinamicamente quando os atendimentos são de (em) espera posto e recomeçado.
    admin:show perf query class "Cisco MOH Device"

    ==>query class :

     - Perf class (Cisco MOH Device) has instances and values:

        MOH_2           -> MOHHighestActiveResources      = 0

        MOH_2           -> MOHMulticastResourceActive     = 0

        MOH_2           -> MOHMulticastResourceAvailable  = 250000

        MOH_2           -> MOHOutOfResources              = 1

        MOH_2           -> MOHTotalMulticastResources     = 250000

        MOH_2           -> MOHTotalUnicastResources       = 250

        MOH_2           -> MOHUnicastResourceActive       = 0

        MOH_2           -> MOHUnicastResourceAvailable    = 250
  • Debugar a música-em-posse do CCM-gerente - Este comando é usado a fim seguir como os trechos de chamada são mudados (quando você desabilita o audio atual e conecta MoH, por exemplo), assim como verificar se o CUBO se junta ao grupo do Internet Group Management Protocol (IGMP) como instruído por CUCM.
  • Debugar o pacote IP - Este comando é usado como uma alternativa a Wireshark para verificações. Contudo, este comando pode rapidamente oprimir o CPU. Use-o somente quando absolutamente necessário; desligue o logging de console, e não o execute para mais do que um segundo.

Cenário 1

Sintoma - Um atendimento da rede telefônica pública comutada (PSTN) estabelece muito bem com áudio de duas vias. Contudo, quando o telefone IP coloca o chamador de PSTN de (em) espera e recomeça então o atendimento, o áudio de sentido único resulta: o telefone IP ouve o áudio do PSTN, mas o usuário PSTN não pode ouvir o telefone IP.

Primeiramente, certifique-se de que exija o SDP que a troca inativa para a mudança dos media do Meados de-atendimento não é desabilitada no tronco do SORVO em question[5]. Esta é o que permite CUCM de enviar um re-CONVITE com o a=inative no SDP, a fim quebrar o trajeto dos media que existe.

Quando o atendimento é de (em) espera posto, CUCM não envia um re-CONVITE com um SDP inativo a fim quebrar o trajeto dos media se Send enviar-recebe o SDP no meados de-atendimento CONVIDA a caixa de verificação é permitida para o SORVO trunk[8]. Essa configuração é verificada somente para ver se há dispositivos que não podem fornecer uma oferta (enviar-RECV) completa depois que o modo dos media é ajustado a inativo.

Estão aqui as imagens que ilustram as caixas de seleção disponíveis:

Nota: Refira a identificação de bug Cisco CSCtx84013 para a informação adicional.

Cenário 2

Sintoma - Há somente um tom quando os chamadores são de (em) espera colocado em vez de MMoH.

Geralmente, isto sugere que CUCM não atribua MMoH.

  • Use a classe da pergunta perf da mostra? Dispositivo MOH de Cisco? Comando CLI CUCM a fim verificar se a contagem de MOHOutOfResources incrementa.
  • Assegure-se de que o Multicast esteja permitido na fonte, no server, e no grupo de MMoH.

Cenário 3

Sintoma - Somente a interrupção é ouvida quando um chamador é de (em) espera colocado.

Assegure que:  

  • O roteamento de transmissão múltipla é permitido no CUBO e no outro Roteadores no caminho de áudio.
  • Roteamento IP e o roteamento de transmissão múltipla são permitidos no Switches L3 no caminho de áudio.
  • O ttl (contagem de saltos) é configurado no server de MoH em CUCM, e é grande bastante cobrir os saltos.
  • Se um transcodificador é exigido, está atribuído com sucesso.
  • A lista de codecs configurados no aplicativo fluente da Voz IP apoia o codec usado para MoH.

Encenação 4

Sintoma - Um atendimento falha no fluxo-em torno do modo para a posse & o resumo do atendimento.

A fim apoiar fluxo-em torno de, você deve enviar um re-CONVITE ou uma atualização do IPIPGW; contudo, isto não é apoiado atualmente. Daqui, fluxo-em torno com dos atendimentos DO-EO não é apoiado. Se há tal exigência do fluxo de chamadas do mercado, uma consideração para o apoio estará feita. O Bug da Cisco, SORVO SS DO-EO do SORVO: O atendimento falha no fluxo em torno do modo para a posse do atendimento & o resumo, é marcado como um realce para a consideração no futuro.

Informações Relacionadas



[1] isto pode ser desconcertante como pode você ter uma conversação diferente dentro de um diálogo? Bem, no SORVO, o diálogo refere a etiqueta do <To 3-tupe, da etiqueta, e o Call-ID>. Este 3-tupe permanece o mesmo durante a fase da posse.

[2] FAZEM - Oferta atrasada.

Tronco inter-grânulo [3]

[4] que parte de CUCM 8.5.

Trabalhos Transcoding [5] para MMoH nas versões do Cisco IOS 15.3T e mais tarde. 

[6] FAZEM - Oferta atrasada

O gerente das comunicações unificadas [7] Cisco caracteriza e presta serviços de manutenção ao guia, liberação 8.6(1)

[8] estes são ajustes no perfil do SORVO usado a fim configurar o tronco do SORVO.



Document ID: 116392