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 >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> 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 >>> [email protected] <mailto:[email protected]> >>> 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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
