CDR details

From YateBTS
Revision as of 16:54, 4 January 2019 by Paulb (Talk | contribs) (CDR files format)

Jump to: navigation, search

The CDRs are build based on /etc/yate/smsc/cdrfile.conf or /etc/yate/ucn/cdrfile.conf files. In the files there are variables used to build the .tsv /.csv file.

CDR files format

Question: Are the records in the CDR files always mixed ?
Answer: Yes, the CDR files are always mixed, there is no warranty regarding the order they are written in the file, you should correlate them by billid.
The records are always build as described in cdrfile.conf file.
This is the header of the table. If a certain value is missing, it won't be added to CDRs and there will be spaces instead of it.

[root@yate-ucn /etc/yate/ucn]# cat cdrfile.conf 
format=${time}  ${route_type$call}      ${component}${connection_id}  ${billid}      ${chan} ${address}      ${caller}       ${called}    \
 ${billtime}    ${ringtime}     ${duration}     ${direction}    ${status}       ${reason}       ${rtp_stats}    \
 ${charging_id} ${imsi} ${imeisv}       ${nsapi}        ${qci}  ${qos}  ${ipv4} ${ipv6} \
 ${inp_pkt}     ${inp_oct}      ${out_pkt}      ${out_oct}      ${rat_type}     ${plmn} ${loc_info}
[root@yate-ucn /etc/yate/ucn]# 

Question: How can we add new fields in the CDR files? (Usage: To record the caller number when he is anonymous)
Answer: First add parameter in the cdrfile.conf (the name of the field) and the 'name_of_variable'
Then also add that parameter name in cdrbuild.conf

echo "asserted_caller=true" >> /etc/yate/ucn/cdrbuild.conf

Question: In CRDs, the records with same billid are they calculated like one SMS? Answer: Yes. In the example below there are two call legs: incoming and outgoing
Is comming through MAP in the SMSC (40744003001) and is sent over HTTP to

[root@yate-smsc old-cdr]# grep 1543926687-18 stmob2__2018-12-04_15-59-11__yate-smsc-cdr.tsv
1543934906.092  msg     SMSC    1543926687-18   MAP     38970003001     40746820086     40744003001     0.002   incoming                                001010302000035
1543934907.104  msg     SMSC    1543926687-18   HTTP      40746820086     40744003001     0.080   outgoing        4
[root@yate-smsc old-cdr]# 

Question: What these fields mean (charging_id, nsapi, qci, qos, inp_pkt, inp_oct, out_pkt, out_oct, rat_type, plmn) ?

  • charging_id - Session specific ID set by GGSN/PGW that allows matching with the SGSN/SGW records
  • nsapi - GERAN/UTRAN NSAPI or EPS Bearer ID, identifier of the data bearer
  • qci - EPS QoS Class Identifier, decimal number, 9 for default Internet service
  • qos - GERAN/UTRAN Quality of Service, in binary format as negotiated
  • inp_pkt - Number of IP packets received from UE (uplink)
  • out_pkt - Number of IP packets sent towards UE (downlink)
  • inp_oct - Number of octets received from UE (uplink)
  • out_oct - Number of octets sent towards UE (downlink)
  • rat_type - Type of the Radio Access Technology; 0 => UTRAN, 2 => GERAN, 6 => E-UTRAN
  • plmn - PLMN ID (MCC+MNC) of the access network
  • loc_info - User Location Info in binary format


Question: What we need to calculate the billing for data (bill_time, duration, inp_oct, out_oct, etc.) ?
Answer: Usually it's inp_oct + out_oct

Question: Is there more that two rows for one call ?

  • A normal call will be 1 row for each channel (call leg)
    • coming to Yate (incoming)
    • going out from Yate (outgoing)
  • on a forwarded call there are 3 rows (assuming Q is calling X, and X has Call Forwarding to Z)
    • 1 incoming: Q is calling X (through Yate)
    • 2 outgoing: Yate to X (X has CF to Z) and Yate to Z
  • The second call: SMSC example says that billtime is 13.944 seconds and that duration is 14.041 seconds.

Question: Why is the time different. Should it be billtime + ringtime = duration, if this is the case why ringtime is 0.000
Answer: Signaling (session negotiation) till 180 Ringing is received; signaling is not ringtime
Voice: if there is no billtime, there is no bill.

  • To bill the called party, you need to bill only one call leg (incoming or outgoing)
  • To bill the caller party, you bill (billtime of incoming)
  • In the scenario you want to bill both caller and called
    • assuming A-MVNO user is roaming in Spain -> and B-MVNO user is calling A (in Spain) -> and you want bill both A (as is called in roaming) and B (as it calls to roaming)
    • you need to bill both incoming and outgoing. This it won't work if called is not your MVNO subscriber

Question: The 'billid' is always unique? In which cases there is only one row for a call?

Answer: Yes, the billid is always uniq for data sessions. For voice calls and SMS it would be the same for inbound and outbound call legs / messages.

For Voice and SMSes CDRs: It is composed of a timestamp (date when Yate service was started) + uniq ID (which is growing incrementally)

[root@yate-ucn old-cdr]# seelogs stmob1__2018-11-29_13-08-57__yate-ucn-cdr.tsv
2018-11-29_13:08:54.249 call    fixed     1543418964-26   sip/51      +40747553298    +40747735711     0.000   0.000   3.565   incoming        progressing     Request Terminated                
2018-11-29_13:08:54.250 call    mvno    1543418964-26   sip/52      +40747553298    +40747735711     0.000   0.000   3.567   outgoing        progressing     Cancelled                         
[root@yate-ucn old-cdr]# seelogs stmob1__2018-11-27_11-59-07__yate-ucn-cdr.tsv
2018-11-27_11:58:56.399 call    mvno    1542795110-172  sip/343      +40746008701    +40745300058    5.686   2.948   11.196  incoming        answered                                          
2018-11-27_11:58:56.400 call    mno     1542795110-172  sip/344      +40746008701    +40745300058    5.691   2.948   11.200  outgoing        answered                                          
[root@yate-ucn old-cdr]# 

For data: Is composed of timestamp (UNIX start time of yate in hexa) - name of GTP-C EP - TEI-C in hexa

[root@yate-ucn old-cdr]# seelogs stmob1__2018-11-28_18-51-14__yate-ucn-cdr.tsv
2018-11-28_18:45:22.028 call    f2m     1543418964-2    sip/3      +38942211451    +3897456923     0.000   0.000   4.934   incoming        progressing     Request Terminated                
2018-11-28_18:45:22.029 call    mvno    1543418964-2    sip/4      +38942211451    +3897456923     0.000   0.000   4.938   outgoing        progressing     Cancelled                         
2018-11-28_18:47:00.233 call    m2m     1543418964-3    sip/6      +38974600870    +38970300058    3.130   4.748   13.704  outgoing        answered                                          
2018-11-28_18:47:00.232 call    mvno    1543418964-3    sip/5      +38974600870    +38970300058    3.135   4.748   13.710  incoming        answered                                          
2018-11-28_18:50:18.309 data    PGW     5bfeb454-pgw0-c/6b2e28f2        pgw0-u/0/6c320ba  38974600870     tkinternet      56.370          56.370  incoming                                113451194  001010302010072 3579990570930006        6       9       1b921f7396fefe74831040006400              0       0       0       0       1       00101   0192f41000651eb9
[root@yate-ucn old-cdr]# 


Question: Can we get all the scenarios for the status column and reason too?

one of incoming, outgoing, ringing, answered or connected, reflecting the current state of the call referred to by this CDR
a (mostly) human readable reason for this CDR.


  • Usually reason is sent by the protocol used there (voice = SIP, sms = MAP, data = MAP/DRA)


[root@yate-smsc smsc]# cat cdrfile.conf
format=${time}  ${route_type$msg}       ${component}${connection_id}    \
 ${billid}      ${protocol}     ${address}      ${caller}       ${called}       \
 ${duration}    ${direction}    ${retries}      ${reason}       \
 ${charging_id} ${imsi}
[root@yate-smsc smsc]# 

Question: The column that is +1 in the CDR files always has value of 4 what is that value?
Answer: This value of 4 is the ${retries} initial value, it begins with 4 (meaning that has maximum 4 retries), if does not succeed, goes to 3, then to 2, then to 1

  • /etc/yate/smsc/yatesmsc.conf:;sms_attempts=3 (by default is 4, this line is commented)
  • Can be configured from MMI -> Equipment -> SMSC-equipment -> SMSC
    • SMS Attempts:: Optional, integer, range [1,30]. How many attempts to make to deliver each SMS. Taken from Extra params if missing.

Question: Is there any way to count the characters of the message so we could incorporate in our billing payment for more than 1 message?
Answer: Below are the CDRs for one SMS that was longer than 160 chars. "just sent sms from +40745867112 to +40747827112"
You don't need to make anything special (the SMSC dispatch the long SMSes as two messages and bills them separately)
For each SMS there is a CDR entry, for long SMSes there are two/or more entries in the CDRs each with different billid

${time} ${route_type$msg} ${component} ${connection_id} ${billid} ${protocol} ${address} ${caller} ${called} ${duration} ${direction} ${retries} ${reason} ${charging_id} ${imsi}

receiving SMSes by SMSC from Maktel
2018-11-29_14:56:02.315 msg     SMSC    1541755391-105  MAP     40744003001     40745867112     40747827112     0.002   incoming                                001010302000034
2018-11-29_14:56:02.467 msg     SMSC    1541755391-106  MAP     40744003001     40745867112     40747827112     0.002   incoming                                001010302000034

sending SMSes:
2018-11-29_14:56:03.277 msg     SMSC    1541755391-105  MAP     40744003001     40745867112     40747827112     1.448   outgoing        4                       001010302000036
2018-11-29_14:56:04.727 msg     SMSC    1541755391-106  MAP     40744003001     40745867112     40747827112     0.156   outgoing        4                       001010302000036

sending delivery report:
2018-11-29_14:56:27.158 msg     SMSC    1541755391-107  MAP     38970003001     38974600869     38974600867     0.002   incoming                                001010302000036
2018-11-29_14:56:28.327 msg     SMSC    1541755391-107  MAP     38970003001     38974600869     38974600867     0.692   outgoing        4                       001010302000034