[Asterisk-biz] Call termination database 0.2

[Alistair Cunningham]

Kevin,

See my comments below.

Alistair Cunningham,
Integrics Ltd,
Telephony, Database, Unix consulting worldwide
+44 (0)7870 699 479
http://integrics.com/


Kevin P. Fleming wrote:
> 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.

Good point; thanks. I've set the mime type to text/plain.

>> - 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).

It's certainly something that people want to know. Do people care enough 
about these that they want to see them in the search results? Would 
having them in the comments field be sufficient?

For that matter, are people going to use the search as their main 
interface, or the downloads of .csv files? If the .csv files are the 
main interface, then this information would be useful to keep in a 
separate field.

> 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.

Not sure what you mean by this. Do you mean a separate database mapping 
    country and area codes to text descriptions? If so, this is easy to 
do at a technical level, but I would need somewhere to download the data 
from. Does anyone know of such a place?

> 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.

The system already does this. I call it 'super ranges' on the site, 
though I don't really like this term, and am looking for a better name. 
If you search for +1212, you will also see offers for the +1 super range 
(assuming your other criteria match). There's aren't any such scenarios 
in the database at the minute, so you had no way of knowing this.

I would argue that if a vendor puts up an offer for +44, then they mean 
+44, not +44[1-2]. If they mean +44[1-2], they should put up 2 offers, 
one for +441 and the other for +442. Any vendor who puts up an offer, 
then when customers make enquiries says "Sorry, we don't include that 
sub range" deserves to get negative feedback.

I'm willing to rethink this if people want. I may be open to more 
powerful searches as well, perhaps with regular expressions, so that 
vendors can omit sub ranges easily. I'll have a think about it.

A tool to help vendors make sure that their offerings are complete and 
competitive would be useful; I'll add it to the todo list.

> _______________________________________________
> Asterisk-Biz mailing list
> Asterisk-Biz at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-biz
> 
>