CDR details

From YateBTS
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 
[general]
file=/var/log/yate-ucn-cdr.tsv
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 10.64.0.15

[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    10.64.0.15      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) ?
Answer:

  • 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

Billing

billid

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  172.25.255.87:5060      +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  172.25.255.71:5060      +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 172.25.255.87:5060      +40746008701    +40745300058    5.686   2.948   11.196  incoming        answered                                          
2018-11-27_11:58:56.400 call    mno     1542795110-172  sip/344 172.25.255.87:5060      +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   172.25.255.87:5060      +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   172.25.255.87:5060      +38942211451    +3897456923     0.000   0.000   4.938   outgoing        progressing     Cancelled                         
2018-11-28_18:47:00.233 call    m2m     1543418964-3    sip/6   172.25.255.71:5060      +38974600870    +38970300058    3.130   4.748   13.704  outgoing        answered                                          
2018-11-28_18:47:00.232 call    mvno    1543418964-3    sip/5   172.25.255.71:5060      +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        62.162.151.110  38974600870     tkinternet      56.370          56.370  incoming                                113451194  001010302010072 3579990570930006        6       9       1b921f7396fefe74831040006400    100.68.0.2              0       0       0       0       1       00101   0192f41000651eb9
[root@yate-ucn old-cdr]# 

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

  • 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: When do I know if call is successful (answered) to bill it ?
Answer: An answered call should have status "answered" and a non-zero billtime.
The CDRs keep separate records for the inbound and outbound call legs linking them together by billid.
For each inbound call leg there will be 0, 1 or more outbound call legs depending on scenario.
Exactly which and how to use depends on your business agreements and whether you are billing the subscriber or another operator.
For subscribers usually it's the outbound call legs as it's where you know how much the route will cost.


Question: Is any of the following statuses represent successful call: progressing, ringing, outgoing, accepted, rejected or incoming?
Answer: Usually a successful / billable call is considered one in "answered" state. Again, it depends on business agreements.


Question: How do we know if caller and/or called number is in roaming?
Answer: Remember that for a MVNO the subscribers are technically always roaming - the question is in which network.
For inbound calls / calling party you can ask Maktel to add some parameter to the SIP INVITE.
For outbound calls / called party it's not possible to know where the subscriber is roaming since you don't have your own GMSC.
It may be possible for Maktel to return that custom information in a SIP 18x or 200 response and it will be available later in call.

Status

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

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

Source: http://docs.yate.ro/wiki/Call.cdr

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

SMS CDRs

[root@yate-smsc smsc]# cat cdrfile.conf
[general]
file=/var/log/yate-smsc-cdr.tsv
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


Question: I saw number 447786205094 (from UK) in our SMSC CDR records, who is this?
Answer: When an iPhone asks to activate iMessage/FaceTime and warns that there may be carrier charges, it sends a SMS to 447786205094 or other number
SMSes are sent every week to that number from all iPhones and cellular enabled iPads
If the carrier supports the iPhone, they shouldn't charge for that SMS.