Melhoria do CMR no CUCM 12.5

Introduction

Este documento descreve os aprimoramentos do Call Management Records (CMR) no Cisco Unified Communications Manager (CUCM) 12.5.

Prerequisites

Requirements

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

• CUCM versão 12.5
• Habilitar registro de detalhes de chamadas (CDR) e CMR no CallManager

Componentes Utilizados

As informações neste documento se baseiam no Cisco Call Manager 12.5(x).

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio 

 O CUCM produz dois tipos de registros, que armazenam o histórico de chamadas e as informações de diagnóstico:

• Registros de detalhes de chamadas - Os registros de dados contêm informações sobre cada chamada processada pelo CallManager.
• Registros de gerenciamento de chamadas - Os registros de dados contêm a qualidade de serviço (QoS) ou informações de diagnóstico sobre a chamada, também chamada de registros de diagnóstico.

Os CDRs e os CMRs juntos são chamados de dados CDR. Os dados CDR fornecem um registro de todas as chamadas feitas ou recebidas pelos usuários do sistema CallManager. Os dados CDR são úteis principalmente para gerar os registros de cobrança; no entanto, ele também pode ser usado para rastrear a atividade das chamadas, diagnosticar certos tipos de problemas e planos de capacidade.

Os CMRs contêm informações sobre a quantidade de dados enviados e recebidos, instabilidade, latência e pacotes perdidos. Inicialmente, o CMR foi gerado para chamadas internas, agora o CUCM pode gerar o CMR para chamadas pelo tronco SIP.

O tronco SIP recebe as estatísticas de chamada no cabeçalho P-RTP-Stat na mensagem BYE ou nas mensagens 200 OK (resposta à mensagem BYE) do CUBE ou IOS Gateway. Essas estatísticas incluem os pacotes RTP (Real-time Transport Protocol) enviados ou recebidos, o total de bytes enviados ou recebidos, o número total de pacotes perdidos, atraso de atraso, atraso de ida e volta e duração da chamada.

O formato do cabeçalho P-RTP-Stat:

P-RTP-Stat: PS=<Pacotes Enviados>, OS=<Octetos Enviados>, PR=<Pacotes Recebidos>, OR=<Octetos Registrados>,PL=<Pacotes Perdidos>, JI=<Jitter>, LA=<Atraso de Viagem Redonda em ms>, DU=<Duração da Chamada em segundos>

É o formato de relatório de estatísticas RTP do gateway do CUBE/SIP IOS. O lado do tronco SIP do CUCM para suporte ao CMR é limitado a esse formato de estatísticas de RTP.

• Após o recebimento de BYE ou 200OK para BYE, o SIPCdpc analisa o cabeçalho P-RTP-Stat e preenche os campos CMR correspondentes com base em pares de valores chave no cabeçalho P-RTP-Stat.

• O SIPCdpc envia o registro de diagnóstico para EnvProcessCdr com dados CMR preenchidos, e EnvProcessCdr cria um arquivo simples e despeja dados CMR nele.

• Nenhum novo campo é adicionado ao CMR como parte deste recurso. Formato existente a ser mantido.

• Qualquer campo no CMR que não seja relevante para que as métricas do lado do tronco (como DiretoryNumber etc.) sejam deixadas em nulo, da mesma forma que as métricas não recebidas do CUBE (por exemplo, varVQMetrics ou métricas de vídeo) sejam deixadas em nulo. 

• Se o cabeçalho P-RTP-Stat não for recebido do CUBE para a mensagem BYE ou 200 OK (resposta para BYE), não haverá registro CMR gravado para o SIPTrunk.

  

Pré-requisito do CUBE para oferecer suporte a este recurso / fornecer estatísticas de chamada:

• O Cisco IOS versão 15.1(3)T ou uma versão posterior deve ser instalado e deve ser executado no Cisco Unified Border Element.
• O Cisco IOS XE versão 3.3S ou uma versão posterior deve ser instalado e deve ser executado no Cisco ASR 1000 Series Router.

Configurações

Etapa 1. O CMR está ativado por meio dos parâmetros de serviço do Call Manager em :

1. Navegar para Sistema > Parâmetro de serviço.
   
   
2. Selecione um servidor na caixa suspensa e selecione o serviço Call Manager

Etapa 2. Defina o parâmetro Call Diagnostics Enabled como:

1. Habilitado somente quando o Sinalizador Habilitado para CDR é Verdadeiro (gerar CMRs somente quando o parâmetro de serviço Sinalizador Habilitado para CDR é definido como Verdadeiro).
   
   

2. Habilitado independentemente do Sinalizador Habilitado para CDR (gera CMRs sem considerar a configuração no parâmetro de serviço Sinalizador Habilitado para CDR).

Análise de rastreamento 

** Incoming BYE from Gateway :



00802148.002 |16:17:01.297 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 539 from 10.106.97.143:[49193]:

[151,NET]

BYE sip:2000@10.106.97.132:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.143:5060;branch=z9hG4bKB41E87

From: <sip:7001@10.106.97.143>;tag=7780842C-12C9

To: <sip:2000@10.106.97.132>;tag=23~30c1033e-90ea-45e0-b1da-eec4a4bfbd�6e-21411553

Date: Tue, 05 Feb 2019 10:03:29 GMT

Call-ID: 1F09F649-286411E9-81B2A4AF-FAF6B880@10.106.97.143

User-Agent: Cisco-SIPGateway/IOS-15.5.3.M5

Max-Forwards: 70

Timestamp: 1549361022

CSeq: 103 BYE

Reason: Q.850;cause=16

P-RTP-Stat: PS=300,OS=48000,PR=365,OR=58400,PL=0,JI=0,LA=0,DU=7

Content-Length: 0





** Post SIPDisconnect Indication, SIPCdpc collects the data



00802151.000 |16:17:01.297 |SdlSig   |SIPDisconnInd                          |active                         |SIPCdpc(1,100,180,5)             |SIPD(1,100,181,1)                |1,100,255,1.62^10.106.97.143^*           |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0]  CcbId= 2�3 --TransType=2 --TransSecurity=0 PeerAddr = 10.106.97.143:49193 Sip_disc_cause= 200 cause=16 isReasonHdrVal= T

00802151.001 |16:17:01.297 |AppInfo  |(isHeldOrHolding): holder=0,holdee=0,mh=0

00802151�.002 |16:17:01.297 |AppInfo  |SIPCdpc(5) - collect_proxyMetricsData: Filling the Audio diagnostic record for the CMR coming from proxy ...

00802151.003 |16:17:01.297 |AppInfo  |SIPCdpc(5) - collect_proxyMetricsData: Audio diagnostics: pktSend = 300, pktSendOct = 48000, pktRec = 365, pktRecOct = 58400, pktLoss = 0, jitter = 0, delay = 0

 

** SIPCdpc sends the data to CDR process to generate CMR



00802193.000 |16:17:01.315 |SdlSig   |DbDiagnosticsReq                       |wait                           |EnvProcessCdr(1,100,6,1)         |SIPCdpc(1,100,180,5)             |1,100,255,1.62^10.106.97.143^*           |[T:N-H:0,N:0,L:0,V:0,Z:0,D:0]  globalCallId: 5 nodeId: 1 directoryNum:  dateTime: 1549363621 numberPa�cketsSent: 300 numberOctetsSent: 48000 numberPacketsReceived: 365 numberOctetsReceived: 58400 numberPacketsLost: 0 jitter: 0 latency: 0 varVQMetrics:





00802252.001 |16:17:01.621 |AppInfo  |EnvProcessCdr::wait_DbDiagnosticsReq

00802252.002 |16:17:01.621 |AppInfo  |EnvProcessCdr::wait_DbDiagnosticsReq DETAILED Entries 2, Inserts 2, ZeroCalls 0

00802252.003 |16:17:01.621 |AppInfo  |EnvProcessCdr::outputCmrData CMR data - 2,1,5,1,"2000",21411554,1549363621,2967,59340,0,0,0,0,0,"1e44e506-9a5d-4f0a-af2c-de23a7405123","","StandAloneCluster","SEPeeeeeeeeeeee","",,"",,,,,,,,,,"","","",,,,,,,,,,"",""

Os dados CMR acima são enviados para o arquivo abaixo de activelog/cm/cdr_repositório/processados/<data atual>/

admin:file list activelog cm/cdr_repository/processed/20190205/*

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Verificar

Na cli, você pode verificar se o CMR é gerado ou não. Para cada data, há uma pasta criada no formato <yyyymmdd>

admin:file list activelog cm/cdr_repository/processed/20190205/*

cmr_StandAloneCluster_01_201902051047_0

dir count = 0, file count = 1

Troubleshoot

 O cabeçalho P-RTP-Stat é recebido em BYE/200OK, mas os dados CMR não são gerados

<Sample BYE message >

00802148.002 |16:17:01.297 |AppInfo  |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 539 from 10.106.97.143:[49193]:

[151,NET]

BYE sip:2000@10.106�.97.132:5060 SIP/2.0

Via: SIP/2.0/UDP 10.106.97.143:5060;branch=z9hG4bKB41E87

From: <sip:7001@10.106.97.143>;tag=7780842C-12C9

To: <sip:2000@10.106.97.132>;tag=23~30c1033e-90ea-45e0-b1da-eec4a4bfbd�6e-21411553

Date: Tue, 05 Feb 2019 10:03:29 GMT

Call-ID: 1F09F649-286411E9-81B2A4AF-FAF6B880@10.106.97.143

User-Agent: Cisco-SIPGateway/IOS-15.5.3.M5

Max-Forwards: 70

Timestamp: 1549361022

CSeq:� 103 BYE

Reason: Q.850;cause=16

P-RTP-Stat: PS=300,OS=48000,PR=365,OR=58400,PL=0,JI=0,LA=0,DU=7

Content-Length: 0

Solução:

Verifique se a controladora de armazenamento habilitada para diagnóstico de chamada está habilitada.

O cabeçalho P-RTP-Stat está presente, mas o CMR não está gravado

<Sample BYE message >

BYE sip:45002@10.77.29.45:5062 SIP/2.0

Via: SIP/2.0/UDP 10.77.22.123:5062;branch=z9hG4bK-11920-1-7

From: sipp <sip:sipp@10.77.22.123:5062>;tag=1

To: sut <sip:45002@10.77.29.45:5062>;tag=2085~b5883d68-042a-4a73-adc3-6be8a5f9f263-24253136

Call-ID: 1-15504@10.77.22.123

CSeq: 1 BYE

Allow-Events: presence, kpml

Contact: sip:sipp@10.77.22.123:5062

Content-Length: 0

P-RTP-Stat: PS=nodata, OS=nodata, PR=nodata, OR=nodata, PL=1, JI=3, LA=0.03, DU=76

Razão:

Como numberPacketsSent e numberPacketsReceived são inválidos, os dados CMR não são despejados no arquivo para Tronco SIP.

Os dados CMR são gerados a partir do cabeçalho P-RTP-Stat, mas alguns valores são gravados incorretamente

<Sample BYE message >

BYE sip:45002@10.77.29.45:5062 SIP/2.0

Via: SIP/2.0/UDP 10.77.22.123:5062;branch=z9hG4bK-11920-1-7

From: sipp <sip:sipp@10.77.22.123:5062>;tag=1

To: sut <sip:45002@10.77.29.45:5062>;tag=2085~b5883d68-042a-4a73-adc3-6be8a5f9f263-24253136

Call-ID: 1-15504@10.77.22.123

CSeq: 1 BYE

Allow-Events: presence, kpml

Contact: sip:sipp@10.77.22.123:5062

Content-Length: 0

P-RTP-Stat: PS=4294967298, OS=1234, PR=4294967298, OR=1233, PL=1, JI=3, LA=0.03, DU=76

Razão:

Como os valores PS e PR estão fora do intervalo (valores maiores que 2^32-1), esses valores fora do intervalo são substituídos pelo valor máximo, ou seja, 2^32-1(4294967295).

Chaves e intervalo de valores permitidos no cabeçalho P-RTP-Stat 

Limitações da função

Este recurso não é suportado para fluxos de chamada SME:

• Ao receber estatísticas de chamadas do CUBE/IOS GW no SME, o CUCM gerará o CMR (desde que o CMR esteja ativado) para o lado do tronco, mas não poderá encaminhar estatísticas de chamadas para outros nós no BYE de saída ou 200OK para o BYE.
• Exemplo de fluxo de chamada:
  Telefone 1 >> CUBE/IOS GW> SME >> CUCM1 >> Telefone 2
  Para o cenário de chamada acima, o SME gerará o CMR para o lado do tronco que aponta para o CUBE . Essas estatísticas não serão encaminhadas para o nó de folha. Para Phone2, o CMR será gravado no nó folha.