CDR details

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]#

Unified LTE/GSM+GPRS core network, including SGSN, GGSN, GMSC, MME, SGW, PGW
See the product here ››


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 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: Some details about ${loc_info}? Is supposed to be decodable then for extra location information.

Answer: ${loc_info} holds the 3GPP-User-Location-Info, please see TS 29.06116.4.7.2 (type = 22) for the encoding used in RADIUS and Diameter.

If you want to decode the loc_info field (User Location Info in binary format), take a look at the examples below:

01 = Contains CGI (GSM)
CGI: 3+2+2 octets
130062 = PLMN 310-260
2775 = LAC 0x2775 = 10101
5aca = Cell ID 0x5aca = 23242

82 = Contains TAI and ECGI (LTE)
TAI: 3 + 2 octets
32f401 = TAI PLMN 234-10
1080 = TAC 0x1080 = 4224
ECGI: 3 + 4 octets
32f401 = ECGI PLMN 234-10
0 = unused
7a2417c = E-UTRAN Cell 0x7a2417c = 128074108

82 = Contains TAI and ECGI (LTE)
TAI: 3 + 2 octets
32f401 = TAI PLMN 234-10
1080 = TAC 0x1080 = 4224
ECGI: 3 + 4 octets
32f401 = ECGI PLMN 234-10
0 = unused
7a24178 = E-UTRAN Cell 0x7a24178 = 128074104

If you just want a Serving PLMN ID you can skip first octet (type) / 2 characters, take the following 3 octets / 6 characters and do a bit of swapping.
The order of nibbles / characters is:

  1. MCC digit 2
  2. MCC digit 1
  3. MNC digit 3 (or F if MNC is 2 digits long)
  4. MCC digit 3
  5. MNC digit 2
  6. MNC digit 1

So if the string is xxABCDEFxxx… the PLMN will be BAD-FEC or BAD-FE


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

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: 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