CDR Accounting in CME Using Gateway Accounting
Gateway accounting provides a useful method in CME to gather Call Detail Records (CDRs) to determine if, when, by who, to whom and how long calls are made. This article provides an end-to-end guide to outputting CDRs in Cisco CME to a SYSLOG server. CDRs can be output in CME to:
- A SYSLOG server (or to local buffer)
- An FTP server
- A local flie
- A RADIUS server
In order to logs CDRs to a SYSLOG server, the following configuration tasks must be performed:
- SYSLOG server operational and on the network
- CME router configured to log to SYSLOG server
- CME router configured for gateway accounting to SYSLOG
The relevant configuration, including SYSLOG commands, is as follows.
logging trap debugging
logging facility local0
logging 192.168.254.2
gw-accounting syslog
For the sake of the example, I install Kiwi SYSLOG daemon on my local PC, so that CDR records can be received. You can use any SYSLOG daemon; I prefer Kiwi since its free, and has a nice, easy to use and familiar interface. If you had a requirement to keep CDRs locally for a finite period of time, you could simply log to the buffer... Just be aware that upon reboot, CDRs are lost, since the device buffer is volatile!
CDRs are logged at level 5 (i.e. notifications), so ensure that your SYSLOG level is either level 5, 6 or 7. Reviewing the levels at IOS level, error levels Notifications, Informational and Debugging all ensure that CDRs are correctly output.
logging trap ?
emergencies System is unusable (severity=0)
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
errors Error conditions (severity=3)
warnings Warning conditions (severity=4)
notifications Normal but significant conditions (severity=5)
informational Informational messages (severity=6)
debugging Debugging messages (severity=7)
We now make an on-net call. Note that CDRs are captured for all CME calls, on-net and off-net. From the output of "show ephone offhook", we can see the two ephones are in a call:
ephone-3[2] Mac:0007.0EA6.2C7B TCP socket:[2] activeLine:1 REGISTERED in SCCP ver 11/9
IP:192.168.254.4 49839 Telecaster 7960 keepalive 31 max_line 6
Active Call on DN 3 chan 1 :7003 192.168.254.4 25112 to 192.168.254.2 24576 via 192.168.255.254
G711Ulaw64k 160 bytes no vad
ephone-4[3] Mac:001A.6BCE.3DC8 TCP socket:[3] activeLine:1 REGISTERED in SCCP ver 9/9
IP:192.168.254.2 52481 CIPC keepalive 1 max_line 8
Active Call on DN 2 chan 1 :7002 192.168.254.2 24576 to 192.168.254.4 25112 via 192.168.255.254
G711Ulaw64k 160 bytes no vad
As soon as the call is terminated, the CDR is written; in our example, to both the local buffer, and to the SYSLOG server. Verify the local log below, and the records written to the remote SYSLOG server in the image below.
Jan 16 20:26:16.431: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId C06251C2E34211DD801B8CCCB267C278, SetupTime 06:26:12.601 AUEST Sat Jan 17 2009, PeerAddress 7002, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 06:26:14.451 AUEST Sat Jan 17 2009, DisconnectTime 06:26:16.431 AUEST Sat Jan 17 2009, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0
Jan 16 20:26:16.431: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:01/17/2009 06:26:12.599,cgn:7002,cdn:,frs:0,fid:11,fcid:C06251C2E34211DD801B8CCCB267C278,legID:B, bguid:C06251C2E34211DD801B8CCCB267C278
Jan 16 20:26:16.439: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId C06251C2E34211DD801B8CCCB267C278, SetupTime 06:26:13.249 AUEST Sat Jan 17 2009, PeerAddress 7003, PeerSubAddress , DisconnectCause 10 , DisconnectText normal call clearing (16), ConnectTime 06:26:14.439 AUEST Sat Jan 17 2009, DisconnectTime 06:26:16.429 AUEST Sat Jan 17 2009, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 0, TransmitBytes 0, ReceivePackets 0, ReceiveBytes 0
Jan 16 20:26:16.439: %VOIPAAA-5-VOIP_FEAT_HISTORY: FEAT_VSA=fn:TWC,ft:01/17/2009 06:26:13.247,cgn:7002,cdn:7003,frs:0,fid:12,fcid:C06251C2E34211DD801B8CCCB267C278,legID:C, bguid:C06251C2E34211DD801B8CCCB267C278
Note that since the call involved 2 on-net parties, there are 2 separate call legs, and therefore 2 sets of CDR messages. These CDR messages are useful for both billing and troubleshooting. Notice in the above you can see *why* a call cleared (Disconnect Text and Cause). This would be particularly useful in troubleshooting.
CME CDR accounting in CME to Kiwi SYSLOG Server
