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

[Andrew Pogrebennyk]

Hello,

the inbound fee - as handbook says - is the termination fee which
applies to callees if you want to charge them for receiving various
calls, e.g. for 800-numbers. It would sum up to customer cost and is not
intended for use in peer relay scenarios.

As you found out, the rate-o-mat is not able to calculate the carrier
cost if there is no subscriber involved. A possible but not as clean
solution is to create subscriber with trusted source = IP or originating
peer. In that case rate-o-mat stored the call origination cost as
customer_cost and termination cost as carrier_cost.

Regards,
Andrew

On 02/04/2014 04:08 PM, Gavin Sweet wrote:
> 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
>>>
>>>
>>>