[Asterisk-biz] Call termination database 0.2

Kevin P. Fleming kpfleming at starnetworks.us
Sun Feb 20 10:18:30 MST 2005


Alistair Cunningham wrote:

> - Downloadable .csv files.

Looks pretty nice; please modify the "downloads" script so that it sets 
a proper MIME-type for the CSV files, so users can open them directly in 
applications if they desire.

> - Lots of other goodies.

Please consider adding billing method (prepaid, postpaid, etc), 
settlement frequency (monthly, weekly, etc) and call duration method 
(1/1, 6/6, 30/6, 60/60, etc).

I think you need a "master route list" that translates destination 
prefixes into country, city/province/region and route type (fixed, 
premium, wireless, satellite, gray, etc). This list should be obtainable 
separately from the termination offers, so that it can be used to build 
LCR tables.

On the vendor side, once this "master route list" is in place, I think 
it would be helpful to somehow _alert_ vendors when they are missing 
routes; for example, if the +44 mobile routes get entered into the list, 
and a vendor puts in a termination offer for +44 but _not_ any of the 
mobile routes (more specific routes inside what they offered), they 
should be somehow warned that their data may be incomplete. In fact, if 
this was _my_ system, I'd be even more aggressive and put in default 
"not available" termination records for that vendor for any 
more-specific route of a different type than the higher level route they 
entered.

In fact, would it be possible for your database to auto-generate routes 
like this? For example, let's say vendor A puts in a termination offer 
for +1, no minimum, fixed route at .01 per minute. Other vendors have 
put in routes for +1212, +1818, +1480 and others (also all "fixed"), but 
vendor A has not. In the complete list then, routes for vendor A would 
appear for +1212, +1818, +1480 with the details repeated from their +1 
offer without them having to actually enter them (unless they do enter 
them, of course). Note that once you have the "route type" implemented 
this will be the critical thing: what I am trying to avoid here is a 
customer assuming that a blanket route for +44 covers all routes within 
+44, when in fact it likely does not cover anything that is not a fixed 
route.



More information about the asterisk-biz mailing list