[OpenSIPS-Users] CDRTool destinations /rates question

Alex Balashov abalashov at evaristesys.com
Wed Jan 21 00:50:57 CET 2009 

Unlike Brian, I am not familiar with CDRtool beyond a cursory level, so 
perhaps I'm headed down the wrong track here.

The general problem seems to be that the multiple destination problem 
(variable-length prefixes) is multidimensional, so it is not just a 
matter of sending to the longest dial prefix match for a given 
destination.  The carrier must also be taken into account.  So, what is 
needed seems to be a destination metric that is a composite rate of a 
gateway and a longest-prefix destination.

The terminating carriers are fixed by a static LCR process.

Is that right, Brian?

Adrian Georgescu wrote:

> Alex, I am trying to understand what precisely you are trying to 
> achieve. What precisely are you working around that cannot be done in a 
> natural way?
> 
> Adrian
> 
> On Jan 20, 2009, at 7:29 PM, Alex Balashov wrote:
> 
>> Good workaround is to use translations in the proxy to prepend a 
>> prefix for each carrier to the DNIS so you can set the rating engine 
>> loose on that.
>>
>> This is how billing systems attached to traditional softswitch EMSs work.
>>
>> Brian Chamberlain wrote:
>>
>>> Thanks Adrian,
>>> As I said, just trying to find an efficient way of doing this, all 
>>> the  providers use different destination names, some have codes that 
>>> don't  exist in the other's databases so trying to pull it all 
>>> together in  CDRtool is proving a bit testing.
>>> It is mentioned as a known limitation
>>> 'The rating engine does not calculate prices based on the outbound 
>>>  carriers or outbound gateways, the rating plan is is assigned by the 
>>>  calling party and not by called party.'
>>> I guess I am trying to figure out an efficient way to deal with the 
>>>  slight nuances with different providers destination codes and 
>>>  descriptions and the overlaps in between..
>>> If it was possible to rate with the destination gateway it would make 
>>>  things a lot easier.
>>> Thanks,
>>> Brian
>>> On 20 Jan 2009, at 15:38, Adrian Georgescu wrote:
>>>> If dest is 1 only rate for dest 1 is applied. There is no longest 
>>>>  match performed for a dest column in a rate table entry.
>>>>
>>>> If you want a rate for 1617, add it to the dest table too.
>>>>
>>>> Adrian
>>>>
>>>> On Jan 20, 2009, at 4:19 PM, Brian Chamberlain wrote:
>>>>
>>>>> Hi Adrian,
>>>>>
>>>>> Thanks for the quick response. As I thought!
>>>>>
>>>>> Can you just confirm that if I have 1 as a destination,1 as a rate 
>>>>>  and also 1617 as a rate and 1617 is the number dialled then 
>>>>>  according to the documentation the rating engine will find the 1 
>>>>>  destination but will do a longest match and find 1617 as the 
>>>>> rating  record or am I hoping for too much?
>>>>>
>>>>> Regards,
>>>>> Brian
>>>>>
>>>>> On 20 Jan 2009, at 15:03, Adrian Georgescu wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> The logic of the rating first determines the destination then it 
>>>>>>  searches for a price for it. So for every entry in destinations 
>>>>>>  table you MUST have an entry in the rates table otherwise the 
>>>>>>  price is zero.
>>>>>>
>>>>>> The best practice is to maintain a central minium destination 
>>>>>>  table common for all customers (add entries to it as it grows) 
>>>>>> and  define custom rates for each of them. Also if you have lot of 
>>>>>>  resellers you can create a main rating table and add only 
>>>>>>  exceptions for the destinations particular to some of them.
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>> On Jan 20, 2009, at 3:56 PM, Brian Chamberlain wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I am sending calls to a number of different sip providers.
>>>>>>> I have rates & destinations from all of them. Some of the providers
>>>>>>> have broken up the amount of destinations into 30,000 different 
>>>>>>>  codes.
>>>>>>> I am trying to build the rates and destinations tables so it is  easy
>>>>>>> to maintain in the future.
>>>>>>>
>>>>>>> Would I be best having a minimal set of destinations to cover each
>>>>>>> country and my local countries/areas and having the rates being  more
>>>>>>> specific.
>>>>>>>
>>>>>>> I suppose my questions are the folowing.
>>>>>>>
>>>>>>> If I have a destination:
>>>>>>>
>>>>>>> 1 USA
>>>>>>>
>>>>>>> and a rate for 1 USA .02
>>>>>>> and a rate for 1617 USA (Boston)
>>>>>>>
>>>>>>> and the customer dials Boston then looking at the logic, even 
>>>>>>>  though I
>>>>>>> don't have a boston Destination CDRTool will still rate the call 
>>>>>>>  using
>>>>>>> the rate for 1617
>>>>>>>
>>>>>>> If the reverse was through and I had a destination 1617 for 
>>>>>>>  boston but
>>>>>>> only a rate for 1 USA would CDRTool use the 1 rate even though it
>>>>>>> found the destination for 1617 in the destinations table?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Users mailing list
>>>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>> Brian Chamberlain
>>>>> Dot Net Solutions Ltd.
>>>>> 68 Parkwest Enterprise Centre,
>>>>> Parkwest,
>>>>> Dublin 12,
>>>>> Ireland.
>>>>> DDI:
>>>>> [+353]
>>>>> 1
>>>>> 6296521
>>>>>
>>>>> FAX:
>>>>> [+353]
>>>>> 1
>>>>> 6237029
>>>>>
>>>>>
>>>>> mobile:
>>>>> [+353]
>>>>> 86
>>>>> 3883003
>>>>>
>>>>>
>>>>>
>>>>> web:
>>>>> www.asterisk.ie <http://www.asterisk.ie>
>>>>>
>>>>> * Looking for the most advanced PBX available that can also save 
>>>>>  you a fortune in communication costs?  asterisk.ie *
>>>>>
>>>>>
>>>>> e-mail disclaimer
>>>>>
>>>>> This e-mail and any files transmitted with it are confidential and 
>>>>>  intended
>>>>> solely for the use of the individual or entity to whom they are 
>>>>>  addressed.
>>>>> If you are not the intended recipient, you are hereby notified that 
>>>>>  any use
>>>>> or dissemination of this communication is strictly prohibited.
>>>>>
>>>>> If you have received this e-mail in error, please advise the sender
>>>>> immediately, then delete this e-mail.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>> Brian Chamberlain
>>> Dot Net Solutions Ltd.
>>> 68 Parkwest Enterprise Centre,
>>> Parkwest,
>>> Dublin 12,
>>> Ireland.
>>> DDI:
>>> [+353]
>>> 1
>>> 6296521
>>> FAX:
>>> [+353]
>>> 1
>>> 6237029
>>> mobile:
>>> [+353]
>>> 86
>>> 3883003
>>> web:
>>> www.asterisk.ie <http://www.asterisk.ie>
>>> * Looking for the most advanced PBX available that can also save you 
>>> a  fortune in communication costs?  asterisk.ie *
>>> e-mail disclaimer
>>> This e-mail and any files transmitted with it are confidential and 
>>>  intended
>>> solely for the use of the individual or entity to whom they are 
>>>  addressed.
>>> If you are not the intended recipient, you are hereby notified that 
>>>  any use
>>> or dissemination of this communication is strictly prohibited.
>>> If you have received this e-mail in error, please advise the sender
>>> immediately, then delete this e-mail.
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> -- 
>> Alex Balashov
>> Evariste Systems
>> Web    : http://www.evaristesys.com/
>> Tel    : (+1) (678) 954-0670
>> Direct : (+1) (678) 954-0671
>> Mobile : (+1) (678) 237-1775
> 


-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

More information about the Users mailing list