Realce CMR em CUCM 12.5
Índice
Introdução
Este original descreve os realces do Call Management Records (CMR) no gerente das comunicações unificadas de Cisco (CUCM) 12.5.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Versão 12.5 CUCM
- Permita o registro de detalhes da chamada (CDR) e o CMR em CallManager
Componentes Utilizados
A informação neste documento é baseada na versão 12.5 do Cisco Call Manager
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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
CUCM produz dois tipos de registros, que armazenam o histórico da chamada e a informação de diagnóstico:
- Os registros de dados dos registros de detalhes da chamada contêm a informação sobre cada atendimento que é processado por CallManager.
- Call Management Records - Os registros de dados contêm o Qualidade de Serviço (QoS) ou a informação de diagnóstico sobre o atendimento, igualmente referido como registros de diagnóstico.
Os CDR e os CMR são referidos junto como dados CDR. Os dados CDR fornecem um registro de todos os atendimentos que foram feitos ou recebidos por usuários do sistema do CallManager. Os dados CDR são úteis primeiramente gerar os registros de faturamento; contudo, podem igualmente ser usados para seguir a atividade de chamada, diagnosticam determinados tipos de problemas e de plano da capacidade.
Os CMR contêm a informação sobre a quantidade de dados enviados e recebidos, tremor, latência, e pacotes perdidos. Inicialmente, o CMR foi gerado para chamadas internas, agora CUCM pode gerar o CMR para atendimentos sobre o tronco do SORVO.
O tronco do SORVO recebe as estatísticas de chamada no encabeçamento P-RTP-Stat na mensagem do ADEUS ou nas 200 mensagens APROVADAS (resposta à mensagem do ADEUS) do CUBO ou do Gateway de IOS. Estas estatísticas incluem os pacotes do Real-Time Transport Protocol (RTP) enviados ou recebidos, bytes total enviados ou recebidos, o número total de pacotes que são perdidos, tremor do atraso, retardo round trip, e duração da chamada.
O formato do encabeçamento P-RTP-Stat:
P-RTP-Stat: PS=<Packets Sent>, OS=<Octets Sent>, PR=<Packets Recd>, OR=<Octets Recd>, PL=<Packets Lost>, JI=<Jitter>, retardo de ida e volta de LA=<Round no ms>, duração de DU=<Call no seconds>
É o formato do relatório das estatísticas do Gateway de IOS RTP CUBE/SIP. O lado do tronco do SORVO CUCM para o apoio CMR é limitado a esse formato de estatísticas RTP.
- Depois que o ADEUS ou 200OK para o ADEUS são recebidos, SIPCdpc analisa gramaticalmente o encabeçamento P-RTP-Stat e povoa os campos correspondentes CMR baseados em pares dos valores chaves no encabeçamento P-RTP-Stat.
- SIPCdpc envia o registro de diagnóstico a EnvProcessCdr com dados povoados CMR, e EnvProcessCdr cria um arquivo plano e despeja dados CMR nele.
- Nenhum campo novo é adicionado ao CMR como parte desta característica. Formato existente a ser mantido.
- Alguns campos no CMR que não forem relevantes para o medidor do lado do tronco (como DirectoryNumber etc.) para ser saido no zero, similarmente para o medidor não recebido do CUBO (medidor por exemplo do varVQMetrics ou do vídeo) a ser saido no zero.
- Se o encabeçamento P-RTP-Stat não está recebido do CUBO para a mensagem do ADEUS ou a APROVAÇÃO 200 (resposta ao ADEUS), não haverá nenhum registro CMR redigido para o SIPTrunk.
A condição prévia do CUBO para apoiar esta característica/fornece estatísticas de chamada:
- O Cisco IOS Release 15.1(3)T ou uma liberação mais atrasada devem ser instalados e devem ser executado em seu Cisco Unified Border Element.
- A liberação 3.3S do Cisco IOS XE ou uma liberação mais atrasada devem ser instaladas e devem ser executado em seu 1000 Series Router de Cisco ASR.
Configurações
Etapa 1. O CMR é permitido através dos parâmetros de serviço do gerente de atendimento abaixo:
- Navegue ao sistema > ao parâmetro de serviço.
- Selecione um server da caixa suspensa e selecione então o serviço do gerente de atendimento
Etapa 2. Ajuste o parâmetro permitido diagnósticos do atendimento a qualquer um:
-
Permitido somente quando a bandeira permitida CDR é verdadeira (gerencia CMR somente quando o parâmetro de serviço permitido CDR da bandeira é ajustado para retificar).
-
Permitido apesar do CDR permitiu a bandeira (gerencie CMR sem consideração ao ajuste no parâmetro de serviço permitido CDR da bandeira).
Análise de traço
** 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 acima CMR são introduzidos no arquivo dentro abaixo do repositório activelog/cm/cdr_repository/processed/<current date>/
admin:file list activelog cm/cdr_repository/processed/20190205/* cmr_StandAloneCluster_01_201902051047_0 dir count = 0, file count = 1
Verificar
Do CLI, você pode verificar se o CMR está gerado ou não. Para cada data, há um dobrador criado no <yyyymmdd> do formato
admin:file list activelog cm/cdr_repository/processed/20190205/* cmr_StandAloneCluster_01_201902051047_0 dir count = 0, file count = 1
Troubleshooting
O encabeçamento 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 o atendimento SP permitido diagnósticos é permitido.
O encabeçamento P-RTP-Stat esta presente mas o CMR não é 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:
Desde que numberPacketsSent e numberPacketsReceived ambos seja inválido, os dados CMR não são despejados no arquivo para o tronco do SORVO.
Os dados CMR são gerados do encabeçamento P-RTP-Stat mas alguns valores são gravados errada
<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:
Desde que os valores PS e PR são fora da escala (valores maiores do que 2^32-1), estes fora dos valores da escala são substituídos com o valor máximo isto é 2^32-1(4294967295).
Chaves e escala permitidas dos valores no encabeçamento P-RTP-Stat
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)