[Spce-user] Peer to peer transit calls - CDRs not properly mediated/rated?

[Gavin Sweet]

Hi Daniel - Thanks.

As expected, there is no match to any billing fee in that record in the cdr
table: customer_billing_fee_id, carrier_billing_fee_id and
reseller_billing_fee_id are all null.

This is a transit call between two peers so there is no subscriber. The CDR
source_provider_id is 2; provisioning.peering_contract_id  /
billing.contract_id 2 is mapped to our billing_profile_id = 1

select bbm.start_date, bbm.end_date, bbp.id, bbp.handle from
billing.billing_profiles bbp, billing.billing_mappings bbm where
bbm.contract_id = '2' and bbm.billing_profile_id = bbp.id \G;

*************************** 1. row ***************************
start_date: NULL
  end_date: NULL
        id: 1
    handle: default
*************************** 2. row ***************************
start_date: 2013-05-10 00:22:04
  end_date: NULL
        id: 10
    handle: SKT_CARRIER_GAMMA


So, there is a billing profile in place for that source provider. 
(And that profile SKT_CARRIER_GAMMA is successfully used for other contracts
also).

The destination user for that call was 4411589xxxxx i.e. 44115 + 7 digits
which is the proper format in the UK.
I have a fee with a destination in this profile that should match this (and
in fact does for other contracts): ^4411[5].{7}$

select id from billing.billing_fees bbf where bbf.billing_profile_id = '10'
and bbf.destination like '^4411[5].{7}$' \G;

id: 138224

select * from billing.billing_fees_history bbfh where bbfh.bf_id = '138224'
\G;

*************************** 1. row ***************************
                      id: 138235
                   bf_id: 138224
      billing_profile_id: 10
billing_zones_history_id: 1909
             destination: ^4411[5].{7}$
                    type: call
        onpeak_init_rate: 0
    onpeak_init_interval: 1
      onpeak_follow_rate: 0.0075
  onpeak_follow_interval: 1
       offpeak_init_rate: 0
   offpeak_init_interval: 1
     offpeak_follow_rate: 0.00666666666666667
 offpeak_follow_interval: 1
           use_free_time: 0
1 row in set (0.00 sec)


Cheers
Gavin


> -----Original Message-----
> From: spce-user-bounces at lists.sipwise.com [mailto:spce-user-
> bounces at lists.sipwise.com] On Behalf Of Daniel Grotti
> Sent: 04 February 2014 13:57
> To: spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] Peer to peer transit calls - CDRs not properly
> mediated/rated?
> 
> Hi Gavin,
> to investigate this issue please start from the following:
> 
> 1. CDR
> mysql> select * from accounting.cdr where
> call_id="35585-3600172261-853630 at MSX28.foobar.com" \G;
> 
> 2. Check inside the billing_fee_id matched.
> 
> 3. check the fee details:
> mysql> select * from billing_fees_history where id=<billing_fee_id>\G
> 
> 
> So you can see which billing profile and fees have been matched and
> which cost has been applied.
> 
> 
> Daniel
> 
> 
> 
> On 02/04/2014 10:10 AM, gavin.sweet at skyracktelecom.com wrote:
> > <Nudge>
> >
> > Any thoughts on why carrier rating might not work as expected...?
> >
> > Thanks,
> > Gavin
> >
> > ----- Reply message -----
> > From: "Gavin Sweet" <gavin.sweet at skyracktelecom.com>
> > To: <spce-user at lists.sipwise.com>
> > Subject: [Spce-user] Peer to peer transit calls - CDRs not properly
> > mediated/rated?
> > Date: Fri, Jan 31, 2014 17:34
> >
> > Hi all -
> >
> >
> >
> > We've been running Sipwise for a long time now with no problems
> > generating correct CDR records for subscriber calls (applying billing
> > profiles etc).
> >
> >
> >
> > We have recently started operating in a transit type model for some
> > peers and are having a problem with CDRs for peer to peer transit
> calls.
> >
> >
> >
> > Calls generate CDR records but they do not contain the
> > expected/correct data in the cost and zone fields, they come out as:
> >  '0.00','0.00','onnet','','platform internal','',
> >
> >
> >
> > E.g.(anonymised):
> >
> > '1002396','2014-01-31
> >
> 15:56:44','0','2','','','','0','02391111111','xxx.yyy.zzz.195','442391
> >
> 111111','0','','0','7','','','','','0','aaa.bbb.ccc.25','441152222222'
> > ,'109.239.110.182','','','call','ok','200','2014-01-31
> > 15:51:02.864','2014-01-31
> > 15:51:07.780','331.830','35585-3600172261-
> 853630 at MSX28.foobar.com','ok
> > ','2014-01-31 15:56:44','0.00','0.00','onnet','','platform
> > internal','','01152222222','0','0'
> >
> >
> >
> > These peering contracts are all setup using exactly the same billing
> > profile as that used for the carrier profile in the subscriber calls
> > that do work properly, so I cant see that it is a problem with the
> profile.
> >
> >
> >
> > For instance the destination fee profile that should match the above
> > is configured as  ^4411[5].{7}$  which works everywhere else for such
> a call.
> >
> >
> >
> > Any one seen a similar problem?
> >
> >
> >
> > Cheers
> >
> > Gavin
> >
> >
> >
> > _______________________________________________
> > Spce-user mailing list
> > Spce-user at lists.sipwise.com
> > http://lists.sipwise.com/listinfo/spce-user
> >
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3684/7050 - Release Date:
> 01/31/14