MMoH através do Guia de Operação, Configuração e Solução de Problemas do CUBE

Introduction

Este documento descreve as informações de operação, configuração e solução de problemas do Multicast Music-on-Hold (MMoH) através do Cisco Unified Border Element (CUBE).

Embora o foco deste documento seja multicast Music-on-Hold (MoH), uma parte substancial é dedicada a descrever como a MoH funciona em geral. Essas informações adicionais ajudam a criar um conhecimento básico para o iniciante, a fim de melhor reconhecer e apreciar os problemas específicos do MMoH.

Note: Embora os princípios sejam os mesmos, o Cisco Unified Border Element-Service Provider Edition (CUBE-SP) não se enquadra no escopo deste documento, nem o uso do CUBE em ambientes que não envolvem o Cisco Unified Communications Manager (CUCM).

Prerequisites

Requirements 

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.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background

Note: Com exceção de alguns cenários ilustrados para o H.323, a sinalização do Session Initiation Protocol (SIP) é usada na maior parte deste documento.

Visão geral do MoH

O MoH é reproduzido sempre que um chamador é colocado em espera. A chamada em espera é iniciada pelo usuário ou pela rede quando um processo de serviço suplementar é implementado, como encaminhamento de chamada ou transferência. O primeiro é conhecido como retenção iniciada pelo usuário, retenção do usuário ou retenção do usuário. Este último é referido como retenção iniciada na rede, retenção na rede ou retenção na rede.

Aqui está uma revisão de como o MoH funciona com os gateways TDM (Time Division Multiplexing, multiplexação por divisão de tempo). Esta imagem ilustra os componentes e conexões envolvidos em um cenário de chamada em espera:

 

Para colocar uma chamada em espera, é necessário um processo em duas etapas. Esta imagem ilustra as duas etapas envolvidas:

 

Tip: Lembre-se deste processo de duas etapas quando tentar classificar a configuração do MoH e solucionar problemas.

Fontes de MoH

O usuário que coloca uma chamada em espera é conhecido como o titular, e o usuário que é colocado em espera (e ouve MoH) é conhecido como o holdee. Cada lado decide certos aspectos da música que é tocada.

 

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

1. A origem da música configurada no Nome de domínio (DN)
2. A origem da música configurada no dispositivo
3. A origem da música no perfil do dispositivo (somente fonte de música de espera do usuário)
4. A origem da música no nível global (parâmetro de serviço ou exemplo)

Há dois conjuntos de fontes de música, chamados de usuário suspenso e de rede em espera. Sempre que se faz referência à fonte de música, ela pode significar uma fonte de música de espera do usuário ou de espera da rede.

Endpoints MoH

Para fins de MoH, o endpoint no lado do CUCM é o servidor MoH. Isso é importante entender porque a determinação do codec (com base na configuração do codec inter-região) é baseada em:

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

A recomendação geral é atribuir ao servidor MoH uma região dedicada, de modo que o codec inter-região entre essa região e todas as outras regiões seja g.711 (ou outro codec que você deseja transmitir para MoH).

Do ponto de vista do CUCM, os endpoints envolvidos na chamada não são os dois telefones, mas sim:

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

Dessa forma, o CUCM trata o tronco que aponta para o gateway/CUBE em questão como o ponto final e examina os recursos associados a ele para determinar como renderizar o fluxo de música.

Protocolo VoIP MoH

O MoH, por definição, é uma conversação de áudio unidirecional. A forma como é sinalizado depende do protocolo VoIP usado. Por exemplo, no SIP, isso é transmitido através do atributo direction. Em H.323, o CUCM especifica 00000000 como o endereço de rede e 0 como a porta (tsapIdentifier) do servidor MoH na mensagem OLCAck (Open Logical Channel Ack) H.245.

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

Nos fluxos de chamada que envolvem o CUBE, o CUCM não tem conhecimento sobre o leg da chamada entre o CUBE e o provedor de serviços de telefonia pela Internet (ITSP). O CUCM se preocupa apenas com o leg da chamada entre o telefone IP e o tronco SIP (levando ao CUBE).

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

Desative o fluxo de mídia

A primeira etapa no processo de duas etapas mencionado anteriormente é desativar o fluxo de mídia.

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

 

As implementações SIP variam se um ou ambos os atributos (?a=? e ?C=IN ?) são usados para indicar que o fluxo de mídia está desabilitado.

Esta imagem ilustra como o fluxo de mídia está desativado no H.323:

  

Conectar ao MoH

A segunda etapa no processo de duas etapas mencionado anteriormente é conectar-se ao MoH. Depois que o fluxo de áudio é desabilitado, o CUCM sinaliza a conversação de MoH unidirecional que faz com que o holdee ouça a origem do MoH.

Como parte desse processo, o CUCM leva em conta os recursos de mídia do holdee e da Lista de Grupos de Recursos de Mídia (MRGL) associados ao tronco antes de determinar os parâmetros para transmissão. Portanto, a sinalização para isso é sempre Oferta atrasada (DO)[2] (no SIP).

O número real de transações de CONVITE varia. Por exemplo, o CUCM conecta o holdee ao MoH com apenas uma transação DO INVITE. Como alternativa, o CONVITE DO é usado para coletar os recursos de mídia do holdee, e um CONVITE DE EO subsequente é usado para realmente conectar o holdee ao MoH.

Esta imagem ilustra a transação para SIP:

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

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

 

Quando os recursos de mídia são usados em uma chamada

Os Recursos de Mídia (MediaTermination Point (MTP) / Transcoders) protegem o leg da chamada do CUBE para o Provedor de Serviços de TI (ITSP) para a maior parte. Quando um recurso de mídia é usado em uma chamada pelo CUBE, a sinalização para MoH envolve principalmente mensagens do Skinny Client Control Protocol (SCCP) entre o CUCM e o recurso de mídia. Observe que é o recurso de mídia que é colocado em espera, não o tronco CUBE. Depois que o MTP/Transcoder é sinalizado para ouvir o MoH (supondo SIP), o CUCM envia uma mensagem SIP UPDATE ao CUBE. Isso atualiza o parâmetro branch, que identifica a nova transação (a conversação MOH).

Retomar a chamada

O processo de retomada é semelhante ao processo em espera, exceto que a ordem é invertida:

1. O fluxo de áudio atual está desativado.
2. É enviado outro CONVITE REAL para reconectar o em espera ao telefone que colocou a chamada em espera. 

Atributo SDP

O atributo X-cisco-media:umoh no Session Description Protocol (SDP) foi introduzido para simplificar a sinalização MoH sobre troncos entre clusters (ICTs)[3]. Com a interoperação entre endpoints que usam protocolos diferentes, o CUCM frequentemente realiza uma sinalização estranha e intermediária que não é intuitiva. Para evitar a suposição e tornar a sinalização contextual explícita, um atributo SDP proprietário, chamado X-cisco-media, é usado.

Com o CUCM versões 8.5 e posteriores, o MoH pode [4] ser sinalizado com este atributo definido como Música Unicast em Espera (UMoH) ou MMoH, o que remove a confiança em um valor de porta falso para indicar um cenário de MoH para a parte reservada.

Note: Isso não afeta a sinalização MoH com CUBE.

MoH no CUBE

Com o CUBE, o processo básico permanece o mesmo; no entanto, é importante considerar que [5] o CUBE não transcodifica o MoH até o Cisco IOS^? Versão 15.3T. Isso significa que você deve ter cuidado com os fatores que influenciam a seleção do codec na perna CUCM-to-CUBE para que um transcodificador não seja necessário.

Note: O transcodificador mencionado aqui é inserido pelo CUBE (ao contrário do CUCM). No que diz respeito ao CUCM, o CUBE é o destino, e não envolve nenhum transcodificador no caminho Servidor para CUBE do MOH.

Considerações sobre codec

Em geral, vários fatores afetam o codec usado na perna do CUCM para o CUBE, mas essas considerações se aplicam ao MoH:

• MoH não pode ser transcodificado.[5]
• O MoH só soa bem com o G.711.

Note: Este tópico está fora do escopo deste documento porque muitos documentos bons já existem em considerações de codec e seria redundante abordá-lo aqui.

MMoH

Note: A maioria das informações descritas neste documento até agora é relevante se o MoH é transmitido com pacotes IP unicast ou multicast.

O MMoH conserva os recursos do sistema e a largura de banda. O multicast permite que vários usuários usem o mesmo fluxo de origem de áudio para fornecer música em espera. O MMoH é desejável em qualquer rede corporativa onde a economia de largura de banda seja importante.

Aqui estão algumas preocupações e problemas quando o CUBE passa o MMoH pela Internet para o ITSP:

• Alcance do tráfego multicast - A Cisco usa o intervalo de 239.0.0.0 a 239.255.255.255 para música multicast. Este intervalo é conhecido como endereços com escopo administrativo. Esse bloco é considerado privado, o que significa que é usado por redes empresariais e nunca deve ser encaminhado para fora da empresa. Geralmente, os roteadores de limite são configurados de acordo.
• Multicast sobre VPN - Por padrão, a segurança IP não suporta MMoH.

É assim que o CUBE suporta o MMoH:

1. O CUBE recebe os pacotes MMoH do servidor MoH.
2. Converte os pacotes em pacotes IP unicast.
3. O CUBE encaminha os pacotes para o ITSP.

Manipulação de atributo de direção SIP

Conforme descrito no RFC 3264:

"Se uma descrição de sessão contiver um fluxo de mídia multicast listado como somente recebimento (envio), significa que os participantes, incluindo o oferente e o respondedor, só poderão receber (enviar) nesse fluxo. Isso difere da visualização unicast, em que o direcionamento se refere ao fluxo de mídia entre o oferente e o respondedor. Além desse esclarecimento, a semântica de um fluxo multicast oferecido é exatamente como descrito no RFC 2327 [1]"

Assim, quando o CUCM envia um CONVITE novamente com um endereço IP multicast, ele define o atributo de direção para recuperação; no entanto, como o CUBE converte os pacotes multicast em pacotes unicast, ele deve definir o atributo de direção como sendonly no segmento com ITSP.

Esta imagem ilustra a lógica:

  

Manipulação de endereço

No CONVITE DO[6] enviado para conectar o chamador ITSP à origem do MoH, o CUBE envia seu próprio endereço IP no campo C=IN do SIP SDP. Este é um endereço unicast.

Essa imagem fornece a exibição de ponta a ponta:

 

Note: O CUBE deve executar o Cisco IOS versão 15.2(2)T ou posterior para oferecer suporte ao MMoH. 

Fluxo de um Flash

Com os gateways TDM, economias adicionais de largura de banda da WAN são obtidas através da transmissão da música multicast diretamente do gateway. Assim, se o servidor MoH estiver na matriz e o gateway estiver em uma filial remota através de uma conexão WAN, o tráfego multicast que transporta MoH não precisará atravessar a WAN (da matriz para a filial) e usar largura de banda WAN valiosa.

O CUBE é um dispositivo do lado do tronco que não é capaz de transmitir o MMoH originado do flash local ou através de qualquer interface TDM analógica. Ainda é possível perceber a largura de banda da WAN. Isso é feito com o uso de outro roteador ativado para voz na filial remota como origem do fluxo MMoH. Este roteador transmite MMoH da memória flash. O CUBE pode então ser sinalizado para receber esses pacotes, convertê-los e passá-los como pacotes unicast.

Fluxo de um feed ao vivo

Para fazer o stream de um feed ao vivo, outro roteador deve ser configurado porque o CUBE não é um dispositivo de lado de linha, conforme discutido na seção anterior.

Configurar o MMoH

Esta seção descreve como configurar o MMoH em switches compatíveis com CUBE, CUCM e L3.

Configurar o MMoH no CUBE

Use estes comandos para configurar o MMoH no CUBE:

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

Configurar o MMoH no CUCM

Siga estas etapas para configurar o MMoH no CUCM:

1. Habilite o recurso multicast na origem MoH, no servidor MoH e no Media Resource Group (MRG).
2. Atribua uma MRGL ao tronco com o MRG configurado na etapa 1.
3. Configure o codec nos parâmetros de serviço do aplicativo de transmissão de voz IP.

Note: Consulte a seção Música em espera do artigo Cisco Unified Communications System 9.0 SRND - Recursos de mídia para obter as etapas detalhadas de configuração.

Configurar o MMoH em switches com capacidade L3

Use estes comandos para configurar o MMoH em switches compatíveis com L3:

ip routing
ip multicast-routing

Quando o MTP é usado em uma chamada

Os MTPs não suportam música multicast. O detentor só recebe ar morto.[7]

Note: Os transcodificadores também são MTPs.

Considerações de desempenho

Todos os pacotes MMOH são comutados por processo no Cisco IOS. Isso é bom para pequenas implantações, mas tem um impacto significativo no desempenho do CUBE para grandes instalações.

Restrições

Aqui está uma lista de restrições com o uso de MMoH:

• O CUBE deve estar na versão 15.2(2)T do Cisco IOS ou posterior.
• O MMoH não é suportado no AS54xx.
• O MMoH não é suportado nos ISR-G1s (28xx, 38xx series)
• Esteja ciente dos codecs suportados.

Troubleshoot

Use esta seção para solucionar problemas de MMoH. 

comandos show e debug

Aqui está uma lista dos comandos show e debug e seus significados:

• Show ccm-manager music - Ajuda a confirmar que o CUBE sabe onde ouvir pacotes de música 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 

• Show ip igmp member - Usado para verificar se o CUBE ingressou com êxito no grupo multicast quando sinalizado para ouvir música multicast.
  
  
• Esses três comandos são usados para verificar o codec negociado, o endereço IP e os números de porta dos endpoints:

  Show call active voice compact
  Show voip rtp conn
  Show sip calls

  Aqui está um exemplo de saída 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

• Show call ative voice brief - Emita este comando quando a chamada está em espera para verificar se a contagem rx/tx aumenta.

  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

• Show perf query class "Cisco MOH Device"- Este comando CUCM CLI é usado para verificar rapidamente se um recurso MoH está alocado e que tipo (unicast ou multicast). Esse comando não é muito útil quando você tem várias chamadas em espera, pois as contagens mudam dinamicamente quando as chamadas são colocadas em espera e retomadas.

  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

• Debug ccm-manager music-on-hold - Este comando é usado para rastrear como os trechos de chamada são alterados (quando você desabilita o áudio atual e conecta o MoH, por exemplo), bem como verificar se o CUBE ingressa no grupo Internet Group Management Protocol (IGMP), conforme instruído pelo CUCM.
• Debug ip packet - Este comando é usado como uma alternativa ao Wireshark para verificações. No entanto, esse comando pode sobrecarregar rapidamente a CPU. Use-o somente quando absolutamente necessário; desative o registro do console e não o execute por mais de um segundo.

Cenário 1

Sintoma - Uma chamada da Rede de Telefonia Comutada Pública (PSTN - Public Switched Telephone Network) é estabelecida normalmente com áudio bidirecional. No entanto, quando o telefone IP coloca o chamador PSTN em espera e retorna a chamada, o áudio unidirecional resulta em: o telefone IP ouve o áudio da PSTN, mas o usuário da PSTN não pode ouvir o telefone IP.

Primeiro, certifique-se de que Require SDP Inative Exchange for Mid-Call Media Change NÃO esteja desabilitado no tronco SIP em questão[5]. Isso é o que permite que o CUCM envie um CONVITE novamente com a=inativo no SDP, para quebrar o caminho de mídia existente.

Quando a chamada é colocada em espera, o CUCM não envia um CONVITE novamente com um SDP inativo para quebrar o caminho da mídia se a caixa de seleção Enviar SDP de recebimento no CONVITE da chamada intermediária estiver habilitada para o tronco SIP[8]. Essa configuração é verificada somente para dispositivos que não podem fornecer uma oferta completa (send-recv) depois que o modo de mídia é definido como inativo.

Aqui estão imagens que ilustram as caixas de seleção disponíveis:

Note: Consulte o bug da Cisco ID CSCtx84013 para obter informações adicionais.

Cenário 2

Sintoma - Há apenas um tom quando os chamadores são colocados em espera em vez de MMoH.

Geralmente, isso sugere que o CUCM não alocou o MMoH.

• Usar a classe show perf query ?Cisco MOH Device? CUCM CLI para verificar se o MOHOutOfResources conta incrementos.
• Verifique se o multicast está habilitado na origem, no servidor e no grupo do MMoH.

Cenário 3

Sintoma - Somente o ar inativo é ouvido quando um chamador é colocado em espera.

Assegure que:  

• O roteamento multicast é ativado no CUBE e em outros roteadores no caminho de áudio.
• O roteamento IP e o roteamento multicast estão ativados nos switches L3 no caminho de áudio.
• O ttl (contagem de saltos) está configurado no servidor MoH no CUCM e é grande o suficiente para cobrir os saltos.
• Se um transcodificador for necessário, ele será alocado com êxito.
• A lista de codecs configurados no Aplicativo de Transmissão de Voz IP suporta o codec usado para MoH.

Cenário 4

Sintoma - Uma chamada falha no modo de fluxo alternativo para Chamada em espera e Retomar.

Para oferecer suporte ao fluxo, você deve enviar um novo CONVITE ou uma atualização do IPIPGW; no entanto, isso não é suportado atualmente. Portanto, o fluxo com chamadas DO-EO não é suportado. Se houver um requisito de fluxo de chamadas do departamento de marketing, será considerada a possibilidade de suporte. O bug da Cisco, SIP SIP SS DO-EO: A chamada falha no modo Fluxo ao redor para Chamada em espera e Retomar, está marcada como uma melhoria para consideração no futuro.

Informações Relacionadas

• Suporte a música em espera multicast no Cisco UBE
• Perguntas frequentes sobre música em espera do CallManager
• Suporte Técnico e Documentação - Cisco Systems

---

[1] Isso pode ser confuso- Como você pode ter uma conversa diferente em um diálogo? Bem, no SIP, a caixa de diálogo se refere à <tag 3-tupe, tag From e Call-ID>. Esta 3-tupe permanece a mesma durante a fase de retenção.

[2] FAZER - Oferta atrasada.

[3] Tronco entre clusters

[4] A partir do CUCM 8.5.

[5] A transcodificação funciona para MMoH no Cisco IOS versões 15.3T e posteriores. 

[6] DO - Oferta atrasada

[7] Guia de recursos e serviços do Cisco Unified Communications Manager, versão 8.6(1)

[8] Estas são as configurações no perfil SIP usado para configurar o tronco SIP.