CDRTool - Handling premium numbers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CDRTool - Handling premium numbers

DanB-2
Folks,

I was wondering what are the solutions from the experts perspective of
rating premium numbers, maybe tricks around the problem.
I know that in many countries (eg: Holland), there are more than 2
millions special premium numbers which should be in theory updated at
least once per day out of external sources like csv files and rated in
cdrs.

* Is there any prefix length limitation in CDRTool for destinations?
* Is CDRTool able to handle them, or do I need an external rating
process. What would be best way to handle them from the point of view of
speed (eg: prepaid)? Would a separate CDRTool instance just for them
make it?
* If the rating should be done in another software, what would be the
best way to identify them in OpenSIPS and create such cdrs to be ignored
by CDRTool when rating normal destinations?

Thanks in advance for any kind of tip!

Cheers,
DanB


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRTool - Handling premium numbers

Adrian Georgescu

On Mar 13, 2009, at 11:22 AM, Dan-Cristian Bogos wrote:

> Folks,
>
> I was wondering what are the solutions from the experts perspective of
> rating premium numbers, maybe tricks around the problem.
> I know that in many countries (eg: Holland), there are more than 2
> millions special premium numbers which should be in theory updated at
> least once per day

In practice in holland you have less then 15K 0900 numbers with  
different prices. Many 0900 ranges share the same price.

> out of external sources like csv files and rated in
> cdrs.

With 8 million different rates doing thousands of simultaneous prepaid  
calls the system load for the rating engine under such traffic is less  
then 3% so you most probably can handle the load.

> * Is there any prefix length limitation in CDRTool for destinations?

No

> * Is CDRTool able to handle them, or do I need an external rating
> process. What would be best way to handle them from the point of  
> view of
> speed (eg: prepaid)?

Yes

> Would a separate CDRTool instance just for them
> make it?

Yes

Regards,
Adrian


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: CDRTool - Handling premium numbers

DanB-2
Hey Adrian,

thanks for impressive fast support.

Some comments inline ...

On Fri, 2009-03-13 at 11:30 +0100, Adrian Georgescu wrote:

> On Mar 13, 2009, at 11:22 AM, Dan-Cristian Bogos wrote:
>
> > Folks,
> >
> > I was wondering what are the solutions from the experts perspective of
> > rating premium numbers, maybe tricks around the problem.
> > I know that in many countries (eg: Holland), there are more than 2
> > millions special premium numbers which should be in theory updated at
> > least once per day
>
> In practice in holland you have less then 15K 0900 numbers with  
> different prices. Many 0900 ranges share the same price.

The list I got from third party was about 2 mil. special numbers in
Holland and, yes, it contained few tens of thousands 0800 (I know that
these must be not charged), few tens of thousands of 0900, but also some
numbers with various prices, staring with prefixes like: 067x, 084x,
087x, 088x (I must admit that I am not 100% familiar with the system you
got there).

> > out of external sources like csv files and rated in
> > cdrs.
>
> With 8 million different rates doing thousands of simultaneous prepaid  
> calls the system load for the rating engine under such traffic is less  
> then 3% so you most probably can handle the load.

This is really useful information, perhaps worth adding in RATING.TXT doc.

Again thanks, you saved me serious devel time.

Cheers,
DanB


> > * Is there any prefix length limitation in CDRTool for destinations?
>
> No
>
> > * Is CDRTool able to handle them, or do I need an external rating
> > process. What would be best way to handle them from the point of  
> > view of
> > speed (eg: prepaid)?
>
> Yes
>
> > Would a separate CDRTool instance just for them
> > make it?
>
> Yes
>
> Regards,
> Adrian
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users