To help clarify, the LERG does not contain local routing information. LCADS does which Telcordia sells but I've heard much better things about the KFR data from people who have compared both. As a point of interest our Qwest team pointed us to localcallingguide as the resource they wanted us to use for local calling areas. Sent from my iPhone On Sep 8, 2010, at 2:13 PM, "Scott Berkman" <scott at sberkman.net> wrote:

Obvious answer, but...

The LERG: http://www.telcordia.com/products_services/trainfo/catalog_details.html

-Scott

-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Corey Edwards Sent: Wednesday, September 08, 2010 4:25 PM To: voiceops at voiceops.org Subject: [VoiceOps] local calling database

Currently I'm using some Perl scripts tied to localcallingguide.com's XML API to build a local calling database, and that seems to be working great, but in the spirit of due diligence I'm looking for feedback about other local calling databases out there, both free and commercial.

On or off list replies appreciated.

Corey

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

The difference between a local calling area and rate center is very confusing, but there is a HUGE difference. A rate center identifies one or more cities that are grouped together so they can be assigned to a particular serving wire center. Local calling areas identify which areas an end user can call for free. Here's the hitch, you can have multiple rate centers in a single local calling area. The only way to find out what the LEC considers a local calling area is to go to the LECs tariff and look it up (which is really what all the fancy databases do for you.) Almost all the LECs are set up pretty similarly in this area so let me show you how to find one and then you can look through any LEC tariff for the rest yourself. Let's just say we want to find the local calling area for Qwest Washington state rate centers. You would go to http://tariffs.qwest.com:8000/Q_Tariffs/QT_Tariff_State_Page/index.htm and select Washington. Then click on Exchange and Network Services Tariff. Then click on section 5.1.1 List of Exchange Areas and Local Calling Areas. It will give you a list like this: Local Exchange and Local Calling Area LOCAL EXCHANGE LOCAL CALLING AREA Aberdeen- Hoquiam Aberdeen-Hoquiam, Copalis, Grayland, Humptulips, Lake Quinault[1], Montesano, Ocosta, Pacific Beach, Westport That means that from Aberdeen-Hoquiam rate center, you can call any of the rate centers on the right. Mary Lou Carey CLEC Consultant BackUP Telecom Consulting marylou at backuptelecom.com 615-791-9969 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Scott Berkman Sent: Thursday, September 09, 2010 3:35 PM To: 'Jed Stafford' Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] local calling database I think it's a terminology difference, and I may not have been clear on which the OP was asking about. The LERG, or Local Exchange Routing Guide, contains information that defines LATAs, Rate Centers, localities, Numbering Plans, and exchange/LRN routing data among other things. I think it is a stretch to say that this does not count as information pertinent to a "local calling database". Local calling areas (which to me refers to what calls are classified as local and are "free" vs. which are LD or more generally "toll" and are charged usage for) are a billing concept usually based on "rating" calls that can differ from carrier to carrier and plan to plan. Telcordia talks about this here http://www.trainfo.com/products_services/tra/catalog_details.html and http://www.trainfo.com/products_services/tra/downloads/tra_catalog.pdf. -Scott -----Original Message----- From: Jed Stafford [mailto:jedsta at gmail.com] Sent: Wednesday, September 08, 2010 5:42 PM To: Scott Berkman Cc: Corey Edwards; <voiceops at voiceops.org> Subject: Re: [VoiceOps] local calling database To help clarify, the LERG does not contain local routing information. LCADS does which Telcordia sells but I've heard much better things about the KFR data from people who have compared both. As a point of interest our Qwest team pointed us to localcallingguide as the resource they wanted us to use for local calling areas. Sent from my iPhone On Sep 8, 2010, at 2:13 PM, "Scott Berkman" <scott at sberkman.net> wrote:

Obvious answer, but...

The LERG: http://www.telcordia.com/products_services/trainfo/catalog_details.htm l

-Scott

-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Corey Edwards Sent: Wednesday, September 08, 2010 4:25 PM To: voiceops at voiceops.org Subject: [VoiceOps] local calling database

Currently I'm using some Perl scripts tied to localcallingguide.com's XML API to build a local calling database, and that seems to be working great, but in the spirit of due diligence I'm looking for feedback about other local calling databases out there, both free and commercial.

On or off list replies appreciated.

Corey

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On Wed, Sep 8, 2010 at 7:52 PM, Alex Balashov <abalashov at evaristesys.com>wrote:

1) NANPA assigned blocks list (available free, publicly).

2) National Pooling assigned blocks list (available free, publicly).

If it's useful to folks, we've got an easy, free way to access that data via HTTP API, HTTP for a browser, and DNS API: http://digits.cloudvox.com/ Like: http://digits.cloudvox.com/2066831234 http://digits.cloudvox.com/2066831234.json It has data for 3, 6, 7, and 10 digit numbers/prefixes, and augments the data with other fields: lat/lng, wireless/wireline access type (guess), ratecenter formatted for display, and nearby metro ratecenter (ie, city). The site has API examples, a Google Spreadsheets custom function that inlines the JSON, and a bookmarklet. If you have special requests, send it via the contact info on the site. We're usually able to add things if it will let someone use it in a new way. Troy

On Mon, Sep 13, 2010 at 8:44 AM, John Todd <jtodd at loligo.com> wrote:

Troy - Excellent, and very useful! However:

Thanks!

a) I tried with just six digits, and it failed. ("We're sorry, but something went wrong.")

Good question. The /10digit path was a nod to convenience for people just starting to use it. The 6 and 7 digit paths are /NPA/NAA and /NPA/NXX/Y, on the grounds that it makes the hierarchy obvious -- that is, if you see /2066831, it's not obvious that /206683 is also a URL, but /206/683/1 makes that clear -- and because API clients performing NPA+NXX queries are likely to be more advanced. They're probably doing some parsing or validation anyway, so expecting split input seemed reasonable. We made sure that /NPA/NXX/YYYY works so that hierarchy is complete. http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api... docs for the paths that do exist.

b) You might consider insisting on fully-qualified e.164 numbers, including the country code, or at least understanding a "+" denotes a fully qualified e.164 number or leading portion of an e.164 number. Why? Because there are some really interesting databases you might add to this that work outside of NANPA, and you don't want to dig a hole you can't get out of with users becoming familiar with a particular type of URL call.

I tried "+12066831234" and it worked great. Fantastic! But then I tried "+22066831234" and that uh... worked as well. And then I tried "+442066831234" and that... astonishingly... worked TOO! So clearly, there is something a bit odd in that API parser.

Yeah, it's very NANPA-centric right now. We wanted to pick a set of information we knew would be complete enough to be useful. I'd love (and have plans to) add other data, and I think if/when there's other data, it would accept /E164 for a specific number and /countrycode/regioncode to browse. We're using Rails' request router with a couple regexes, so the parser can almost certainly be confused if you try (though I believe it works for all the documented cases). I'm okay with garbage in, garbage out ;-) Canada will probably be next up since we have the data and it's easy to parse. If anyone has pointers to downloadable CSVs for another country and would consume the service if that country was added, email me offlist. Troy

For current ( I haven't found a mistake yet ) porting information. Check out http://tnid.org/

I just checked a friend who ported his landline to wireless last week Friday and the info there is incorrect...do you think they're dipping live? Frank -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jared Geiger Sent: Monday, September 13, 2010 2:34 PM To: VoiceOps Subject: Re: [VoiceOps] local calling database For current ( I haven't found a mistake yet ) porting information. Check out http://tnid.org/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

On 09/13/2010 02:43 PM, Chris Boyd wrote:

How is the carrier information determined? I've tried a few numbers, and the city/state infor was correct, but the carrier information was incorrect. The numbers were reported as the carrier that originally provisioned service, not the current carrier after porting.

Well, yes. That is going to be true of any static database. Porting information is queried in real-time to NPAC, by design. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

It does indeed, but is clearly doing real-time to a data source of some description. It may be cached data, but still queried dynamically. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Sep 13, 2010, at 4:26 PM, Chris Boyd <cboyd at gizmopartners.com> wrote:

On Sep 13, 2010, at 2:47 PM, Alex Balashov wrote:

...

Well, yes. That is going to be true of any static database. Porting information is queried in real-time to NPAC, by design.

Thanks, Alex. I missed the part about it being static. http://tnid.org/ that Jared mentioned does show the current carrier correctly.

--Chris _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops