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

Thu Feb 6 07:38:23 EST 2014

Thanks Andrew.

Just to check my understanding, you are suggesting configuring a subscriber
(real, but only used for this purpose) who is associated with the
appropriate billing profile, and will catch the calls for rating purposes by
having peer IP in his trusted source?
Does that work for 2.7/2.8 as well as 3 and 3.1?

Cheers Gavin

> -----Original Message-----
> From: Andrew Pogrebennyk [mailto:apogrebennyk at sipwise.com]
> Sent: 05 February 2014 15:11
> To: gavin.sweet at skyracktelecom.com; 'Daniel Grotti'; spce-
> user at lists.sipwise.com
> Subject: Re: [Spce-user] Peer to peer transit calls - CDRs not properly
> mediated/rated?
> 
> 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','44239
> >> 1
> >>>
> >>
> 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
> >>>
> >>>
> >>>
> -----
> 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