Os clientes, às vezes, têm a necessidade de registrar Registros Detalhados de Chamadas (CDRs) em sistemas de Voz sobre IP (VoIP) para fins de auditoria ou orçamento. A maneira recomendada de se fazer isto é com um servidor externo de autenticação, autorização e auditoria (AAA) (RADIUS ou TACACS). Esses sistemas AAA freqüentemente fornece registro CDR, processamento de registro pós-chamadas e um recurso de geração de relatórios de faturamento.
Pode haver algumas situações em que a complexidade ou o custo do servidor AAA proíba seu uso, mas ainda há um requisito para o registro CDR. Neste caso, é possível usar as capacidades de syslog do gateway ou roteador Cisco para registrar VoIP CDRs em um servidor externo de syslog. Esses registros estão no formato CSV (variável separada por vírgulas). Eles podem ser facilmente carregados e processados por um aplicativo de software externo, como uma planilha ou um banco de dados. O software do servidor de syslog pode ser executado em um PC básico. O download de aplicações de servidor syslog básico pode ser feito na Internet. A Cisco não faz recomendações sobre nenhum tipo específico de versão do software servidor syslog.
O Syslog usa UDP como o mecanismo de transporte básico para que os pacotes de dados não tenham seqüência e não sejam confirmados. É possível que em uma rede pesada utilizada, alguns pacotes possam ser descartados e, portanto, as informações de CDR são perdidas. Vários servidores de SYSLOG podem ser especificados para redundância.
Para que o timestamp no CDR esteja correto, há um requisito para que o roteador ou gateway do Cisco IOS® seja configurado para sincronização de tempo através de uma fonte de tempo do Network Time Protocol (NTP). Se o roteador não tiver sincronização de NTP, os tempos de início e parada de cada CDR terão valor zero (null). Se uma origem NTP externa não estiver disponível, o roteador precisará definir um NTP mestre. Isso é explicado na seção Configuração.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Este é um exemplo de configuração que permite ao roteador gerar CDRs VoIP e enviá-los a um servidor syslog externo:
router(config)#service timestamps log datetime msec localtime !--- Ensures that the records are timestamped with an accurate value. ! router(config)#aaa new-model ! router(config)#aaa authentication login default none !--- Enables AAA to prevent Telnet authentication via AAA. router(config)#aaa accounting connection h323 start-stop radius !--- Generates the H.323 call start/stop CDRs. router(config)#gw-accounting syslog !--- Sends the H.323 CDRs to the syslog server. router(config)#logging 10.64.6.250 !--- The IP address of the syslog server. Multiple syslog servers !--- can be specified for redundancy.
O NTP deve ser executado no roteador ou gateway do Cisco IOS para garantir que os registros de início/parada H.323 tenham o valor de hora correto. Estes são os dois métodos do NTP:
Use este comando de configuração global do software Cisco IOS para sincronizar o roteador ou gateway do Cisco IOS com um servidor NTP externo:
router(config)#ntp server ip address
ip address — O endereço IP do servidor de hora que fornece a sincronização de relógio.
Se não houver nenhuma origem de tempo NTP externa, use o relógio interno como a origem de tempo. Isso é feito com o comando de configuração global do software Cisco IOS mostrado aqui:
router(config)#ntp master
O relógio do roteador deve ser definido para a hora correta (do modo EXEC normal) com este comando para garantir que os timestamps estejam corretos:
router#clock set 15:15:00 8 May 2001
Observação: em algumas plataformas da Cisco, o relógio do roteador não tem backup com uma fonte de bateria. O tempo do sistema precisa ser redefinido após uma recarga do roteador ou uma falha de energia.
Essa é uma parte da saída do console do roteador. Quando a configuração neste documento é habilitada, os CDRs são direcionados para o console do roteador e para o servidor syslog. Para remover o registro do console do roteador, configure no logging console no modo de configuração global no roteador. Evita que os CDRs e outras mensagens do sistema apareçam no console, mas ainda ficam conectados ao servidor syslog.
Quando uma chamada VoIP é feita, ela coloca uma chamada na direção de encaminhamento para o destino. O destino faz uma chamada de retorno para que ocorra uma conexão VoIP full-duplex. Portanto, existe um CDR para o segmento de encaminhamento e um segundo CDR para o segmento de retorno. O leg da chamada direta tem uma origem de chamada de 2, enquanto o leg da chamada de retorno tem uma origem de chamada de 1.
Observação: algumas linhas de saída são divididas em várias linhas para fins de impressão.
router# !--- This output is for the forward call leg. Jun 18 11:15:02.867: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId BA55719E F8C10015 0 1B1E08, SetupTime 11:14:39.367 UTC Mon Jun 18 2001, PeerAddress 68575, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing., ConnectTime 11:14:49.707 UTC Mon Jun 18 2001, DisconnectTime 11:15:02.867 UTC Mon Jun 18 2001, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 1509, TransmitBytes 102600, ReceivePackets 1510, ReceiveBytes 138920 router# !--- This output is for the reverse call leg. Jun 18 11:15:02.983: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId BA55719E F8C10015 0 1B1E08, SetupTime 11:14:41.683 UTC Mon Jun 18 2001, PeerAddress 2887, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing., ConnectTime 11:14:49.703 UTC Mon Jun 18 2001, DisconnectTime 11:15:02.983 UTC Mon Jun 18 2001, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 1510, TransmitBytes 102692, ReceivePackets 1509, ReceiveBytes 138828 router#
Este CDR mostra:
Segmento de chamada de encaminhamento | |
---|---|
Gerado por CDR de tempo | : Jun 18 11:15:020,867 |
ID de conexão única | : BA55719E F8C10015 0 1B1E08 |
Hora de configuração | : 11:14:39.367 UTC Seg 18 Jun 2001 |
PeerAddress (Número de chamada) | : 68575 |
Desconecte o código de causa | : 10 |
Texto da causa da desconexão | : limpeza normal de chamada |
Hora de conexão | : 11:14:49.707 UTC Seg 18 Jun 2001 |
Origem de chamada | : 2 |
Tempo de desconexão | : 11:15:02.867 UTC, Segunda, 18 de junho de 2001 |
Transmitir pacotes | : 1509 |
Bytes de transmissão | : 102600 |
Pacotes de recepção | : 1509 |
Bytes de recepção | : 138828 |
Retornar segmento de chamada | |
---|---|
Gerado por CDR de tempo | : Jun 18 11:15:02.983 |
Identificador de conexão | : BA55719E F8C10015 0 1B1E08 |
Hora de configuração | : 11:14:41.683 UTC Seg 18 Jun 2001 |
PeerAddress (número chamado) | : 2887 |
Desconecte o código de causa | : 10 |
Texto da causa da desconexão | : limpeza normal de chamada |
Hora de conexão | : 11:14:49.703 UTC segunda-feira 18 de junho de 2001 |
Origem de chamada | : 1 |
Tempo de desconexão | : 11:15:02.983 UTC Seg 18 Jun 2001 |
Transmitir pacotes | : 1510 |
Bytes de transmissão | : 102692 |
Pacotes de recepção | : 1509 |
Bytes de recepção | : 138828 |
A desconexão causa valores de código padrão para hexadecimal. Esta tabela mostra alguns valores hexadecimais comuns e suas explicações:
Valor hexadecimal | Explicação |
---|---|
0x0 | Veja a observação abaixo |
0x1 | Número não atribuído |
0x3 | Sem rota para o destino |
0x10 | Limpeza normal de chamada |
0x11 | Usuário ocupado |
0x12 | Sem resposta do usuário |
0x13 | Sem atendimento do usuário |
0x15 | Chamada rejeitada |
0x1C | Número inválido |
0x1F | Normal, não especificado |
0x22 | Sem circuito |
0x2C | Nenhum circuito foi solicitado |
0x2F | Sem recurso |
0x3F | Serviço ou opção não disponível, não especificado |
Observação: algumas versões do software Cisco IOS podem fornecer muitas mensagens do código de causa de desconexão "0" quando o comando show h323 gateway cause-codes é emitido. É um defeito cosmético e não tem impacto no desempenho.