In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data. TelcoData.com doesn't keep City/State or Lat/Long coordinates of the NPANXX, only the switch that serves the block. The problem is that, for example in DC, Washington DC Zone 17 seems to be served from Beltsville, MD, but 571-269-3 is a Virginia, likely Arlington, exchange. So taking the switch location as the lat/lon for the npanxx block is very incorrect. Cloudvox's API is awesome (Thanks Cloudvox!), but outside of Country, Region and Ratecenter, the city and location data from their API has been somewhat wrong. Examples: http://digits.cloudvox.com/571/269/3 Ratecenter: WSNGTNZN17 VA City: WSNGTNZN08 (what?!?) Lat/Lon: 37.4315734, -78.6568942 (the center of Virginia, not even close to the DC area) http://digits.cloudvox.com/805/316 Ratecenter: SNLUSOBSPO CA City: SANBARBARA (Not a valid city name) Lat/Lon: 36.778261, -119.4179324 (155 miles from San Luis Obispo, CA) There are others, but I won't bore you. To give them credit, they have a "geo_precision" which I assume tells you how many significant digits you can trust, but is not mentioned in the API docs ( http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api ) Plus it is limited to US only (recently addressed here or on asterisk-biz, may change). LocalCallingGuide.com is a bit better at their lat/lon, but they don't include City name, they only offer XML and not JSON or another parseable format, and they don't list the ratecenter in the LERG 10 char format. http://localcallingguide.com/xmlprefix.php?npa=571&nxx=269 I'm expecting WSNGTNZN17, not "Washington Zone 17" as the Ratecenter. Between the TelcoData.com, three, I can inconsistently and automatedly get the data I need. I'd like to start offering a map of numbers available, but the map is only as good as the data behind it. Is there another more accurate source that people use? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Peter - I strongly suspect that you describe below a systematic problem with switch/NPAXXX mapping, as you indicate. The exact example you use may be a bit misleading as to the extent of those errors, though. Bear in mind that the DC area has some very strange things in their phone mapping, in particular, the Beltsville CO which you identify. There are facilities served out of the Beltsville CO which are, shall we say, "non-standard". The Arlington exchange you reference may be significantly farther away from the switch than is typical. The Beltsville CO may show some unusual mappings; I would suggest you don't use it as an indicator or test case given the number of technically complex government use cases in that area. The first (or second?) data T1 we had almost installed in our office in Beltsville was an interesting example, though not directly voice-related. The Bell Atlantic technician wired it up into our then- empty building, and asked "Is the tech at White Sands available to do an end-to-end test?" Since we were expecting a T1 to go about six miles down the road, this was a surprise. He looked at the expression on our faces, looked back at his paperwork, and said "Whoops. Let me get back to you in a few hours with YOUR circuit." Lastly: Your phrase of "inconsistently and automatedly get the data I need" is a truism for number-to-geography mapping these days. Ultimately, there is a growing lack of geographic association with numbers, and the relative value of doing that association is diminishing. For instance, I have no phone numbers associated with me on a common basis that mapped to a switch that is within 2000 miles of where I sit most often. While I am a phone geek, this is growing more common even with friends who are not in the telephony industry. Other than an increasingly inaccurate curiosity (pretty maps with lots of lines!) I don't see much use for geographic association in the future. JT On Sep 20, 2010, at 11:08 AM, Peter Beckman wrote:
In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data.
TelcoData.com doesn't keep City/State or Lat/Long coordinates of the NPANXX, only the switch that serves the block. The problem is that, for example in DC, Washington DC Zone 17 seems to be served from Beltsville, MD, but 571-269-3 is a Virginia, likely Arlington, exchange. So taking the switch location as the lat/lon for the npanxx block is very incorrect.
Cloudvox's API is awesome (Thanks Cloudvox!), but outside of Country, Region and Ratecenter, the city and location data from their API has been somewhat wrong. Examples:
http://digits.cloudvox.com/571/269/3 Ratecenter: WSNGTNZN17 VA City: WSNGTNZN08 (what?!?) Lat/Lon: 37.4315734, -78.6568942 (the center of Virginia, not even close to the DC area)
http://digits.cloudvox.com/805/316 Ratecenter: SNLUSOBSPO CA City: SANBARBARA (Not a valid city name) Lat/Lon: 36.778261, -119.4179324 (155 miles from San Luis Obispo, CA)
There are others, but I won't bore you. To give them credit, they have a "geo_precision" which I assume tells you how many significant digits you can trust, but is not mentioned in the API docs ( http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api ) Plus it is limited to US only (recently addressed here or on asterisk-biz, may change).
LocalCallingGuide.com is a bit better at their lat/lon, but they don't include City name, they only offer XML and not JSON or another parseable format, and they don't list the ratecenter in the LERG 10 char format.
http://localcallingguide.com/xmlprefix.php?npa=571&nxx=269
I'm expecting WSNGTNZN17, not "Washington Zone 17" as the Ratecenter.
Between the TelcoData.com, three, I can inconsistently and automatedly get the data I need. I'd like to start offering a map of numbers available, but the map is only as good as the data behind it.
Is there another more accurate source that people use?
Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Mon, 20 Sep 2010, John Todd wrote:
I strongly suspect that you describe below a systematic problem with switch/NPAXXX mapping, as you indicate. The exact example you use may be a bit misleading as to the extent of those errors, though. Bear in mind that the DC area has some very strange things in their phone mapping, in particular, the Beltsville CO which you identify. There are facilities served out of the Beltsville CO which are, shall we say, "non-standard". The Arlington exchange you reference may be significantly farther away from the switch than is typical. The Beltsville CO may show some unusual mappings; I would suggest you don't use it as an indicator or test case given the number of technically complex government use cases in that area.
Your phrase of "inconsistently and automatedly get the data I need" is a truism for number-to-geography mapping these days. Ultimately, there is a growing lack of geographic association with numbers, and the relative value of doing that association is diminishing. For instance, I have no phone numbers associated with me on a common basis that mapped to a switch that is within 2000 miles of where I sit most often. While I am a phone geek, this is growing more common even with friends who are not in the telephony industry. Other than an increasingly inaccurate curiosity (pretty maps with lots of lines!) I don't see much use for geographic association in the future.
Thanks John! True, some of the larger metro areas are convoluted, including the Beltsville CO as you mention. However it's clear it is possible to provide at least somewhat accurate information, at least a GeoPoint on a map that is within some arbitrarily drawn ratecenter boundry. While geographic association continues to decrease with the ability of people getting phone numbers from anywhere and have them ring wherever they are, the NANPA and LATA setup isn't going away anytime soon. Everyone in my neighborhood who has a home phone has it within the same exchange or three. Many businesses still rely on having local neighborhood numbers. It may go away someday, but right now there is still a demand for local numbers, and people prefer numbers (for whatever reason) in a familiar exchange where possible. I've found ratecenter maps: http://www.truevectortech.com/industries/telecom/ but they aren't overlayed on something like Google Maps, so they are less useful. People in NYC are surprisingly fickle about their phone number and its "location." Until that ends, I still need accurate NPANXX/LERG mappings not to the switch (clearly) but to a general service area. Speaking of ratecenter boundries, other than the map example above, where would one get a hold of the ratecenter boundries in some GIS-type mappable format? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On 9/20/2010 2:54 PM, Peter Beckman wrote:
On Mon, 20 Sep 2010, John Todd wrote:
I strongly suspect that you describe below a systematic problem with switch/NPAXXX mapping, as you indicate. The exact example you use may be a bit misleading as to the extent of those errors, though. Bear in mind that the DC area has some very strange things in their phone mapping, in particular, the Beltsville CO which you identify. There are facilities served out of the Beltsville CO which are, shall we say, "non-standard". The Arlington exchange you reference may be significantly farther away from the switch than is typical. The Beltsville CO may show some unusual mappings; I would suggest you don't use it as an indicator or test case given the number of technically complex government use cases in that area.
Your phrase of "inconsistently and automatedly get the data I need" is a truism for number-to-geography mapping these days. Ultimately, there is a growing lack of geographic association with numbers, and the relative value of doing that association is diminishing. For instance, I have no phone numbers associated with me on a common basis that mapped to a switch that is within 2000 miles of where I sit most often. While I am a phone geek, this is growing more common even with friends who are not in the telephony industry. Other than an increasingly inaccurate curiosity (pretty maps with lots of lines!) I don't see much use for geographic association in the future.
Thanks John! True, some of the larger metro areas are convoluted, including the Beltsville CO as you mention. However it's clear it is possible to provide at least somewhat accurate information, at least a GeoPoint on a map that is within some arbitrarily drawn ratecenter boundry.
While geographic association continues to decrease with the ability of people getting phone numbers from anywhere and have them ring wherever they are, the NANPA and LATA setup isn't going away anytime soon. Everyone in my neighborhood who has a home phone has it within the same exchange or three. Many businesses still rely on having local neighborhood numbers. It may go away someday, but right now there is still a demand for local numbers, and people prefer numbers (for whatever reason) in a familiar exchange where possible.
I've found ratecenter maps:
http://www.truevectortech.com/industries/telecom/
but they aren't overlayed on something like Google Maps, so they are less useful. People in NYC are surprisingly fickle about their phone number and its "location." Until that ends, I still need accurate NPANXX/LERG mappings not to the switch (clearly) but to a general service area.
Speaking of ratecenter boundries, other than the map example above, where would one get a hold of the ratecenter boundries in some GIS-type mappable format?
Beckman ---------------------------------------------------------------------------
Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ -
How do you geo-map for cell-only households which has grown past 15% of the market now? In my own circle of non-telecom friends, very few have a landline and most have a cell phone with an area code outside Tampa. LATA boundaries really only affect ILEC's. CLEC's offer LATA wide and state-wide calling in some cases. VoIP isn't exactly rate center based EXCEPT with ported numbers. - Peter
On Mon, 20 Sep 2010, Peter R. wrote:
How do you geo-map for cell-only households which has grown past 15% of the market now? In my own circle of non-telecom friends, very few have a landline and most have a cell phone with an area code outside Tampa.
Obviously if you have a NY cell phone and live in FL, it won't be accurate. That's impossible. But I _CAN_ show where that NY cell phone resides in the NANPA world, or at least a rough estimate. Sure, some ratecenters cover hundreds of miles, but for the most part you can get a good handle on where a number originates from. I don't care about where the device that rings when you call a number is located. Privacy issues abound there. I'm merely looking for a definitive source of Geo-telecom data for NANPA.
LATA boundaries really only affect ILEC's. CLEC's offer LATA wide and state-wide calling in some cases. VoIP isn't exactly rate center based EXCEPT with ported numbers.
What VoIP isn't rate center based? Sure, billing may not be, but that doesn't cause an npanxx not to be linked to a physical location. And some providers still do full npanxx based call decks. Sometimes you want to give the customer some insight into the call -- if you don't have a name, give an accurate location at least (more than a state). I know my provider, VoIPo, sends information like "Anytown OH Mobile" or similar when a name isn't available. That's useful! Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
On Mon, Sep 20, 2010 at 11:08 AM, Peter Beckman <beckman at angryox.com> wrote:
In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data.
We ran the ratecenter through Google's geocoder, in some cases with a bit ofB preprocessing and/or filters (state/county where known). But it's very much a best guess. Our goal with Digits has been to expose everything we can provide for free. Sometimes that's quite reliable (rate center), some of which is mostly accurate (carrier, city), and some of which is a crapshoot (lat/lng). Cloudvox's API is awesome (Thanks Cloudvox!), but outside of Country,
Region and Ratecenter, the city and location data from their API has been somewhat wrong. Examples:
You're very welcome.
http://digits.cloudvox.com/571/269/3 Ratecenter: WSNGTNZN17 VA City: WSNGTNZN08 (what?!?) Lat/Lon: 37.4315734, -78.6568942 (the center of Virginia, not even close to the DC area)
http://digits.cloudvox.com/805/316 Ratecenter: SNLUSOBSPO CA City: SANBARBARA (Not a valid city name)
Lat/Lon: 36.778261, -119.4179324 (155 miles from San Luis Obispo, CA)
Those are cases of garbage in, garbage out. We start with mediocre data (ratecenter string like "WSNGTNZN17") and run with it as far as possible. Some ("SEATTLE") are easier than others :-) I'd definitely consider replacing these lat/lng values with the CO lat/lng if you're able to find an unencumbered copy. I think you're right that they would be more accurate. As far as current accuracy, it depends on what you want to do with the data. It's completely unsuitable for making call routing or rating decisions. It's ideal for customizing/localizing IVRs, displaying inline maps, analyzing CDRs, deciding whether to offer a SMS menu choice, data appending, and the like, because all of those depend on depth of data and flexibility more than accuracy. Regarding John Todd's note that wireless users and VoIP carriers have decoupled number from location, a byproduct is that for non-routing uses, that makes Digits about as accurate as anything else -- not because Digits is dead on, but because nothing else is anymore either. Digits might be 50 miles off, but there's a good chance that a wireless subscriber is 50 miles from their area code center anyway, so the API consumer already expects imprecision (except for routing). There are others, but I won't bore you. To give them credit, they have a
"geo_precision" which I assume tells you how many significant digits you can trust, but is not mentioned in the API docs ( http://help.cloudvox.com/faqs/digits/digits-phone-number-location-lookup-api)
Good catch, and thanks for the heads up. I just added geo_precision to the docs and examples, and clarified its meaning and where lat/lng come from. Cheers, Troy http://twitter.com/troyd
On Mon, 20 Sep 2010, Troy Davis wrote:
On Mon, Sep 20, 2010 at 11:08 AM, Peter Beckman <beckman at angryox.com> wrote:
In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data.
We ran the ratecenter through Google's geocoder, in some cases with a bit ofB preprocessing and/or filters (state/county where known). But it's very much a best guess. Our goal with Digits has been to expose everything we can provide for free. Sometimes that's quite reliable (rate center), some of which is mostly accurate (carrier, city), and some of which is a crapshoot (lat/lng).
Those are cases of garbage in, garbage out. We start with mediocre data (ratecenter string like "WSNGTNZN17") and run with it as far as possible. Some ("SEATTLE") are easier than others :-)
I'd definitely consider replacing these lat/lng values with the CO lat/lng if you're able to find an unencumbered copy. I think you're right that they would be more accurate.
Actually I was saying in some cases it would be way inaccurate. Take 571-269. The CO is listed as Beltsville, MD, but the rate center is listed as being in a different state entirely. Using the CO lat/lng would confuse the issue. I used to think the CO lat/long would be more accurate, but I've learned otherwise.
As far as current accuracy, it depends on what you want to do with the data. It's completely unsuitable for making call routing or rating decisions. It's ideal for customizing/localizing IVRs, displaying inline maps, analyzing CDRs, deciding whether to offer a SMS menu choice, data appending, and the like, because all of those depend on depth of data and flexibility more than accuracy.
Yep. Though it would be great to try to get the City name normalized to a real city name, rather than NWYRCYZN01 for a ratecenter of NWYRCYZN15.
Regarding John Todd's note that wireless users and VoIP carriers have decoupled number from location, a byproduct is that for non-routing uses, that makes Digits about as accurate as anything else -- not because Digits is dead on, but because nothing else is anymore either. Digits might be 50 miles off, but there's a good chance that a wireless subscriber is 50 miles from their area code center anyway, so the API consumer already expects imprecision (except for routing).
Good catch, and thanks for the heads up. I just added geo_precision to the docs and examples, and clarified its meaning and where lat/lng come from.
Thanks for the clarification and link! I've started a wiki page on voip-info.org to try to put our collective heads together about regions and ratecenter names that don't map nicely to a city name. Any other thoughts are appreciated. I'll make it prettier tomorrow. http://www.voip-info.org/wiki/view/NANPA+Rate+Centers --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
The most accurate info would be to get what the PSAPs have... Frank -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Peter Beckman Sent: Monday, September 20, 2010 9:23 PM To: Troy Davis Cc: VoiceOps Subject: Re: [VoiceOps] Rate Center Maps, Locations for NPANXXs On Mon, 20 Sep 2010, Troy Davis wrote:
On Mon, Sep 20, 2010 at 11:08 AM, Peter Beckman <beckman at angryox.com> wrote:
In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data.
We ran the ratecenter through Google's geocoder, in some cases with a bit ofB preprocessing and/or filters (state/county where known). But it's very much a best guess. Our goal with Digits has been to expose everything we can provide for free. Sometimes that's quite reliable (rate center), some of which is mostly accurate (carrier, city), and some of which is a crapshoot (lat/lng).
Those are cases of garbage in, garbage out. We start with mediocre data (ratecenter string like "WSNGTNZN17") and run with it as far as possible. Some ("SEATTLE") are easier than others :-)
I'd definitely consider replacing these lat/lng values with the CO lat/lng if you're able to find an unencumbered copy. I think you're right that they would be more accurate.
Actually I was saying in some cases it would be way inaccurate. Take 571-269. The CO is listed as Beltsville, MD, but the rate center is listed as being in a different state entirely. Using the CO lat/lng would confuse the issue. I used to think the CO lat/long would be more accurate, but I've learned otherwise.
As far as current accuracy, it depends on what you want to do with the data. It's completely unsuitable for making call routing or rating decisions. It's ideal for customizing/localizing IVRs, displaying inline maps, analyzing CDRs, deciding whether to offer a SMS menu choice, data appending, and the like, because all of those depend on depth of data and flexibility more than accuracy.
Yep. Though it would be great to try to get the City name normalized to a real city name, rather than NWYRCYZN01 for a ratecenter of NWYRCYZN15.
Regarding John Todd's note that wireless users and VoIP carriers have decoupled number from location, a byproduct is that for non-routing uses, that makes Digits about as accurate as anything else -- not because Digits is dead on, but because nothing else is anymore either. Digits might be 50 miles off, but there's a good chance that a wireless subscriber is 50 miles from their area code center anyway, so the API consumer already expects imprecision (except for routing).
Good catch, and thanks for the heads up. I just added geo_precision to the docs and examples, and clarified its meaning and where lat/lng come from.
Thanks for the clarification and link! I've started a wiki page on voip-info.org to try to put our collective heads together about regions and ratecenter names that don't map nicely to a city name. Any other thoughts are appreciated. I'll make it prettier tomorrow. http://www.voip-info.org/wiki/view/NANPA+Rate+Centers --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If you look in the LERG 8 Rate Center, it lists the V & H coordinates for each rate center. Also LERG 8 Locality lists each city (abbreviated name and full name) associated with each rate center. Mary Lou Carey BackUP Telecom Consulting 615-791-9969 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Frank Bulk Sent: Friday, September 24, 2010 11:00 PM To: 'Peter Beckman'; Troy Davis Cc: VoiceOps Subject: Re: [VoiceOps] Rate Center Maps, Locations for NPANXXs The most accurate info would be to get what the PSAPs have... Frank -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Peter Beckman Sent: Monday, September 20, 2010 9:23 PM To: Troy Davis Cc: VoiceOps Subject: Re: [VoiceOps] Rate Center Maps, Locations for NPANXXs On Mon, 20 Sep 2010, Troy Davis wrote:
On Mon, Sep 20, 2010 at 11:08 AM, Peter Beckman <beckman at angryox.com> wrote:
In the past I've paid MelissaData.com $400 or so to get access to their NPANXX-Ratecenter-Location-GIS data. For each NPANXX, they list the Ratecenter, City and state/region, Lat/Lon coordinates. It's fairly accurate, though I'm not entirely sure how they get the data.
We ran the ratecenter through Google's geocoder, in some cases with a bit ofB preprocessing and/or filters (state/county where known). But it's very much a best guess. Our goal with Digits has been to expose everything we can provide for free. Sometimes that's quite reliable (rate center), some of which is mostly accurate (carrier, city), and some of which is a crapshoot (lat/lng).
Those are cases of garbage in, garbage out. We start with mediocre data (ratecenter string like "WSNGTNZN17") and run with it as far as possible. Some ("SEATTLE") are easier than others :-)
I'd definitely consider replacing these lat/lng values with the CO lat/lng if you're able to find an unencumbered copy. I think you're right that they would be more accurate.
Actually I was saying in some cases it would be way inaccurate. Take 571-269. The CO is listed as Beltsville, MD, but the rate center is listed as being in a different state entirely. Using the CO lat/lng would confuse the issue. I used to think the CO lat/long would be more accurate, but I've learned otherwise.
As far as current accuracy, it depends on what you want to do with the data. It's completely unsuitable for making call routing or rating decisions. It's ideal for customizing/localizing IVRs, displaying inline maps, analyzing CDRs, deciding whether to offer a SMS menu choice, data appending, and the like, because all of those depend on depth of data and flexibility more than accuracy.
Yep. Though it would be great to try to get the City name normalized to a real city name, rather than NWYRCYZN01 for a ratecenter of NWYRCYZN15.
Regarding John Todd's note that wireless users and VoIP carriers have decoupled number from location, a byproduct is that for non-routing uses, that makes Digits about as accurate as anything else -- not because Digits is dead on, but because nothing else is anymore either. Digits might be 50 miles off, but there's a good chance that a wireless subscriber is 50 miles from their area code center anyway, so the API consumer already expects imprecision (except for routing).
Good catch, and thanks for the heads up. I just added geo_precision to the docs and examples, and clarified its meaning and where lat/lng come from.
Thanks for the clarification and link! I've started a wiki page on voip-info.org to try to put our collective heads together about regions and ratecenter names that don't map nicely to a city name. Any other thoughts are appreciated. I'll make it prettier tomorrow. http://www.voip-info.org/wiki/view/NANPA+Rate+Centers --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- _______________________________________________ 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
participants (6)
-
beckman＠angryox.com -
frnkblk＠iname.com -
jtodd＠loligo.com -
marylou＠backuptelecom.com -
peter＠4isps.com -
troy＠yort.com