Topics

dialing plan database

Chris Hodges
 

I am new to local calling guides. This is an impressive database. I especially like the XML query interface.


I have noticed that some of the dialing plans reported by localcallingguides differ from the NANPA database.


For instance:


http://www.localcallingguide.com/xmldialplan.php?npa=812


reports a standard toll call to a foreign NPA to be 10 digits. NANPA reports 11 digits. Also in the same area code, localcallingguides reports 10 digit for local home dialing, yet NANPA reports 7 digits.


Being new these databases, which is considered the more accurate?


czg7777@...
 

Considering that NANPA is the original source of the dial plan data, I can only conclude that they have made some updates since the last time I downloaded it from them.

Chris Hodges
 

Thanks for your response. I have written C++ code in MS VC and Android Java code to query your server. Is there an equivalent query interface for the NANPA site that you use to get the NANPA area code data?

I am no expert at HTTP programming and have not figured out how to submit the area code to the input field on the NANPA area code search page (http://www.nationalnanpa.com/enas/npa_query.do). I can bring up the page asking for the area code (input field 'npaId') using WinHTTP, but do not know how to send the area code (fill in the input field) to the page so it gives me the area data in response.

Thanks for any help you can give me.



On 12/6/2014 3:47 PM, czg7777@... [local-calling-guide] wrote:
 

Considering that NANPA is the original source of the dial plan data, I can only conclude that they have made some updates since the last time I downloaded it from them.


czg <czg7777@...>
 

As far as I know, NANPA does not provide an API. My site used to have a query that would retrieve the dial plan information from NANPA but they have changed their site to accept only HTTP POST and likely have added some hidden fields to their form to prevent automated retrieval.


On Sunday, December 7, 2014 11:46 AM, "Chris Hodges nvideon@... [local-calling-guide]" wrote:




Thanks for your response. I have written C++ code in MS VC and Android Java code to query your server. Is there an equivalent query interface for the NANPA site that you use to get the NANPA area code data?

I am no expert at HTTP programming and have not figured out how to submit the area code to the input field on the NANPA area code search page (http://www.nationalnanpa.com/enas/npa_query.do). I can bring up the page asking for the area code (input field 'npaId') using WinHTTP, but do not know how to send the area code (fill in the input field) to the page so it gives me the area data in response.

Thanks for any help you can give me.



On 12/6/2014 3:47 PM, czg7777@... [local-calling-guide] wrote:
 
Considering that NANPA is the original source of the dial plan data, I can only conclude that they have made some updates since the last time I downloaded it from them.





Richard Currie <rcurrie@...>
 

Chris:

You might find the cURL library to be helpful. Here is a link to
the documentation.

http://curl.haxx.se/docs/httpscripting.html

Regards, Rich

On 07/12/2014 8:43 AM, Chris Hodges nvideon@... [local-calling-guide] wrote:
Thanks for your response. I have written C++ code in MS VC and Android
Java code to query your server. Is there an equivalent query interface
for the NANPA site that you use to get the NANPA area code data?

I am no expert at HTTP programming and have not figured out how to
submit the area code to the input field on the NANPA area code search
page (http://www.nationalnanpa.com/enas/npa_query.do). I can bring up
the page asking for the area code (input field 'npaId') using WinHTTP,
but do not know how to send the area code (fill in the input field) to
the page so it gives me the area data in response.

Thanks for any help you can give me.

Chris Hodges
 

Rich,

Thanks, but normally you can fill in the input fields by appending ?fieldname=value to the url request. For instance:

http://www.nationalnanpa.com/enas/npa_query.do?npaId=404&submit=Continue

but that does not yield any results.

czg7777@... suggested that NANPA has put some code in the website to prevent queries like that. Not being any kind of HTML expert I am stumped.

Chris


On 12/7/2014 3:12 PM, Richard Currie rcurrie@... [local-calling-guide] wrote:
 

Chris:

You might find the cURL library to be helpful. Here is a link to
the documentation.

http://curl.haxx.se/docs/httpscripting.html

Regards, Rich

On 07/12/2014 8:43 AM, Chris Hodges nvideon@...
[local-calling-guide] wrote:
> Thanks for your response. I have written C++ code in MS VC and Android
> Java code to query your server. Is there an equivalent query interface
> for the NANPA site that you use to get the NANPA area code data?
>
> I am no expert at HTTP programming and have not figured out how to
> submit the area code to the input field on the NANPA area code search
> page (http://www.nationalnanpa.com/enas/npa_query.do). I can bring up
> the page asking for the area code (input field 'npaId') using WinHTTP,
> but do not know how to send the area code (fill in the input field) to
> the page so it gives me the area data in response.
>
> Thanks for any help you can give me.


Richard Currie <rcurrie@...>
 

Chris,

When you put the parameter/value pairs in the URL the program receives it via GET, whereas the program you are trying to invoke uses PUT.
(That is what czg7777 was getting at.)

It is critical that you use the PUT method for what you are trying to accomplish. That cURL library I mentioned allows one to send a PUT to
an HTTP server. Once you understand the difference between GET and PUT
you should be on your way to doing what you want to do. I have used the PHP version of the cURL library to do something very similar.

So there is your Sunday homework, Rich :-)

On 07/12/2014 2:06 PM, Chris Hodges nvideon@... [local-calling-guide] wrote:
Rich,

Thanks, but normally you can fill in the input fields by appending
?fieldname=value to the url request. For instance:

http://www.nationalnanpa.com/enas/npa_query.do?npaId=404&submit=Continue

but that does not yield any results.

czg7777@... suggested that NANPA has put some code in the website
to prevent queries like that. Not being any kind of HTML expert I am
stumped.

Chris

Chris Hodges
 

Rich,

WinHTTP can also POST and PUT. I am guessing you meant POST, not PUT. PUT seems to be for storing the data on the web server and POST seems to be for submitting the data to be acted upon (like in a form). Whenever I PUT or POST using MS WinHTTP I get a response the PUT or POST is not a supported method.

I tried the same thing with cURL

curl --data "npaID=404&submit=Continue" www.nationalnanpa.com/enas/npa_quer.do

and got the same result.

Request method 'POST' not supported

I don't know enough about how HTTP requests work to know what is going on. Am I totally confused about what I am doing or is there a trick I have not understood?

Thanks,
Chris


On 12/7/2014 5:25 PM, Richard Currie rcurrie@... [local-calling-guide] wrote:
 

Chris,

When you put the parameter/value pairs in the URL the program receives
it via GET, whereas the program you are trying to invoke uses PUT.
(That is what czg7777 was getting at.)

It is critical that you use the PUT method for what you are trying to
accomplish. That cURL library I mentioned allows one to send a PUT to
an HTTP server. Once you understand the difference between GET and PUT
you should be on your way to doing what you want to do. I have used the
PHP version of the cURL library to do something very similar.

So there is your Sunday homework, Rich :-)

On 07/12/2014 2:06 PM, Chris Hodges nvideon@...
[local-calling-guide] wrote:
> Rich,
>
> Thanks, but normally you can fill in the input fields by appending
> ?fieldname=value to the url request. For instance:
>
> http://www.nationalnanpa.com/enas/npa_query.do?npaId=404&submit=Continue
>
> but that does not yield any results.
>
> czg7777@... suggested that NANPA has put some code in the website
> to prevent queries like that. Not being any kind of HTML expert I am
> stumped.
>
> Chris


Richard Currie <rcurrie@...>
 

Chris,

Sorry about my brain-fart -- Yes I meant to write POST instead of PUT!
I'll try to put something together in PHP to test a POST call to npa_quer.do when I have a moment.

Waters muddied while you wait, Rich

On 07/12/2014 4:07 PM, Chris Hodges nvideon@... [local-calling-guide] wrote:
Rich,

WinHTTP can also POST and PUT. I am guessing you meant POST, not PUT.
PUT seems to be for storing the data on the web server and POST seems to
be for submitting the data to be acted upon (like in a form). Whenever I
PUT or POST using MS WinHTTP I get a response the PUT or POST is not a
supported method.

I tried the same thing with cURL

curl --data "npaID=404&submit=Continue"
www.nationalnanpa.com/enas/npa_quer.do

and got the same result.

Request method 'POST' not supported

I don't know enough about how HTTP requests work to know what is going
on. Am I totally confused about what I am doing or is there a trick I
have not understood?

Thanks,
Chris

Richard Currie <rcurrie@...>
 

Chirs,

I took a look at the source code for the npa_quer.do page and
the form one fills out gets POSTed to the module area_code_query.do
and the parameter holding the NPA is npaId (not npaID).

So your code was POSTing to the wrong module with an incorrect parameter name.

I wrote this code in PHP to do what you were trying to do, and
result I got was an error page with no useful information.

<?php
$url = 'http://www.nationalnanpa.com/enas/area_code_query.do';
$post = array('npaId' => '404');

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_POST,1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$result=curl_exec($ch);
curl_close ($ch);
echo $result;
?>

You might want to try your code with the area_code_query.do
URL and the npaId parameter.

Good luck, Rich

On 07/12/2014 4:07 PM, Chris Hodges nvideon@... [local-calling-guide] wrote:
Rich,

WinHTTP can also POST and PUT. I am guessing you meant POST, not PUT.
PUT seems to be for storing the data on the web server and POST seems to
be for submitting the data to be acted upon (like in a form). Whenever I
PUT or POST using MS WinHTTP I get a response the PUT or POST is not a
supported method.

I tried the same thing with cURL

curl --data "npaID=404&submit=Continue"
www.nationalnanpa.com/enas/npa_quer.do

and got the same result.

Request method 'POST' not supported

I don't know enough about how HTTP requests work to know what is going
on. Am I totally confused about what I am doing or is there a trick I
have not understood?

Thanks,
Chris

Chris Hodges
 

Rich,

I had two typos in my e-mail. Sorry about that. My actual code used the correct url and parameter. I just tried it again just in case with the same result. Wish I knew more about HTTP coding.

Thanks,
Chris


On 12/7/2014 9:09 PM, Richard Currie rcurrie@... [local-calling-guide] wrote:
 

Chirs,

I took a look at the source code for the npa_quer.do page and
the form one fills out gets POSTed to the module area_code_query.do
and the parameter holding the NPA is npaId (not npaID).

So your code was POSTing to the wrong module with an incorrect parameter
name.

I wrote this code in PHP to do what you were trying to do, and
result I got was an error page with no useful information.

$url = 'http://www.nationalnanpa.com/enas/area_code_query.do';
$post = array('npaId' => '404');

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_POST,1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$result=curl_exec($ch);
curl_close ($ch);
echo $result;
?>

You might want to try your code with the area_code_query.do
URL and the npaId parameter.

Good luck, Rich

On 07/12/2014 4:07 PM, Chris Hodges nvideon@...
[local-calling-guide] wrote:
> Rich,
>
> WinHTTP can also POST and PUT. I am guessing you meant POST, not PUT.
> PUT seems to be for storing the data on the web server and POST seems to
> be for submitting the data to be acted upon (like in a form). Whenever I
> PUT or POST using MS WinHTTP I get a response the PUT or POST is not a
> supported method.
>
> I tried the same thing with cURL
>
> curl --data "npaID=404&submit=Continue"
> www.nationalnanpa.com/enas/npa_quer.do
>
> and got the same result.
>
> Request method 'POST' not supported
>
> I don't know enough about how HTTP requests work to know what is going
> on. Am I totally confused about what I am doing or is there a trick I
> have not understood?
>
> Thanks,
> Chris


Chris Hodges
 

Firefox has an add-on (iMacro) that automates filling in forms through a script. I used that to get all of the NANPA dialing plan data. Here are the discrepancies between the NANPA database and the local calling guide database:


             NANPA Data               Local Calling Guide
NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
------------------------------------------------------------
204:   10D,   10D, 1+10D, 1+10D -    7D,   10D, 1+10D, 1+10D
274:   10D, 1+10D, 1+10D, 1+10D -   10D, 1+10D,   10D, 1+10D
327:   10D,   10D, 1+10D, 1+10D -    7D,   10D, 1+10D, 1+10D
415:    7D, 1+10D,    7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
447: 1+10D, 1+10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
464: 1+10D, 1+10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
557:   10D,   10D, 1+10D, 1+10D -   10D, 1+10D,   10D, 1+10D
564:   10D,   10D, 1+10D, 1+10D -    7D,   10D, 1+10D, 1+10D
615:    7D,    7D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
659:   10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
689:   10D,   10D, 1+10D, 1+10D -    7D, 1+10D, 1+10D, 1+10D
702:   10D, 1+10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
740:    7D,   10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
812:    7D,   10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
825:   10D,   10D, 1+10D, 1+10D -   10D, 1+10D, 1+10D, 1+10D
843:    7D,   10D, 1+10D, 1+10D -   10D,   10D, 1+10D, 1+10D
975:   10D,   10D, 1+10D, 1+10D -   10D, 1+10D,   10D, 1+10D


drew@...
 

Is it possible that all of these NPAs are currently transitioning from
one to the other, or are actually behaving differently in reality than
how NANPA describes that it should? For example, I see 740 on the below
list, and the difference between the two lists is LHNPA. Planning letter
471 indicates that the current state of 740 is 7D Standard and 10D
Permissive, but the NANPA NPA Code Search system indicates that 740 is
7D Standard and NA Permissive.

On Sat, Dec 13, 2014, at 19:34, nvideon@... [local-calling-guide]
wrote:
Firefox has an add-on (iMacro) that automates filling in forms through a
script. I used that to get all of the NANPA dialing plan data. Here are
the discrepancies between the NANPA database and the local calling guide
database:


NANPA Data Local Calling Guide
NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
------------------------------------------------------------
204: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
274: 10D, 1+10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
327: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
415: 7D, 1+10D, 7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
447: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
464: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
557: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
564: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
615: 7D, 7D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
659: 10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
689: 10D, 10D, 1+10D, 1+10D - 7D, 1+10D, 1+10D, 1+10D
702: 10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
740: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
812: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
825: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 1+10D, 1+10D
843: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
975: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D


Chris Hodges
 

Thanks for the feedback Drew. Are you saying the local calling guide data may be more accurate? Czg7777@... indicated that the NANPA was the source of the local calling guide data.

I can only assume that NANPA data should be used only as a best guess as to how the actual plan is implemented. In Atlanta, AT&T (formerly Bell South) require all local calls to be dialed as 10D without the 1. It has been this way ever since Atlanta transitioned from one area code of 404 and 7 digit local dialing to multiple area codes and 10D local dialing back in the 90's. However, the NANPA data indicates 1+10D is permitted for local dialing which is clearly wrong. There is no reason I know of that 404, 770, 678, and 470 area codes in and around Atlanta could not accept both 10 and 11 digit dialing for local calls. But I am not intimately familiar with the switching equipment they use, so perhaps there is a reasonable explanation.

On 12/13/2014 11:21 PM, drew@... [local-calling-guide] wrote:
�

Is it possible that all of these NPAs are currently transitioning from
one to the other, or are actually behaving differently in reality than
how NANPA describes that it should? For example, I see 740 on the below
list, and the difference between the two lists is LHNPA. Planning letter
471 indicates that the current state of 740 is 7D Standard and 10D
Permissive, but the NANPA NPA Code Search system indicates that 740 is
7D Standard and NA Permissive.

On Sat, Dec 13, 2014, at 19:34, nvideon@... [local-calling-guide]
wrote:
> Firefox has an add-on (iMacro) that automates filling in forms through a
> script. I used that to get all of the NANPA dialing plan data. Here are
> the discrepancies between the NANPA database and the local calling guide
> database:
>
>
> NANPA Data Local Calling Guide
> NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
> ----------------------------------------------------------
> 204: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
> 274: 10D, 1+10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
> 327: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
> 415: 7D, 1+10D, 7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
> 447: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 464: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 557: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
> 564: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
> 615: 7D, 7D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 659: 10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
> 689: 10D, 10D, 1+10D, 1+10D - 7D, 1+10D, 1+10D, 1+10D
> 702: 10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 740: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 812: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 825: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 1+10D, 1+10D
> 843: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
> 975: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
>
>
>


drew@...
 

I'm not necessarily saying that it's more accurate... just pondering
whether or not there might be some logic and reason to the differences.
NPA 740 just recently began 10D (Permissive), and that is not currently
reflected in the NANPA NPA Code Search system, but it is indicated as
standard in the local calling guide. I do not personally have knowledge
of how any of these systems are maintained, or how the data is
maintained, but that specific difference makes me wonder if someone or
something is updating the local calling guide records using some source
other than the NANPA NPA Code Search system.

I also agree with your assumption that NANPA's dialplan data is "best
guess", or perhaps "desired state". In my experience, it is definitely
unsafe to rely upon that information when configuring CPE or
communicating to end users.

On Sun, Dec 14, 2014, at 21:06, Chris Hodges nvideon@...
[local-calling-guide] wrote:
Thanks for the feedback Drew. Are you saying the local calling guide
data may be more accurate? Czg7777@... indicated that the NANPA
was the source of the local calling guide data.

I can only assume that NANPA data should be used only as a best guess as
to how the actual plan is implemented. In Atlanta, AT&T (formerly Bell
South) require all local calls to be dialed as 10D without the 1. It has
been this way ever since Atlanta transitioned from one area code of 404
and 7 digit local dialing to multiple area codes and 10D local dialing
back in the 90's. However, the NANPA data indicates 1+10D is permitted
for local dialing which is clearly wrong. There is no reason I know of
that 404, 770, 678, and 470 area codes in and around Atlanta could not
accept both 10 and 11 digit dialing for local calls. But I am not
intimately familiar with the switching equipment they use, so perhaps
there is a reasonable explanation.

On 12/13/2014 11:21 PM, drew@... [local-calling-guide] wrote:

Is it possible that all of these NPAs are currently transitioning from
one to the other, or are actually behaving differently in reality than
how NANPA describes that it should? For example, I see 740 on the below
list, and the difference between the two lists is LHNPA. Planning letter
471 indicates that the current state of 740 is 7D Standard and 10D
Permissive, but the NANPA NPA Code Search system indicates that 740 is
7D Standard and NA Permissive.

On Sat, Dec 13, 2014, at 19:34, nvideon@... [local-calling-guide]
wrote:
Firefox has an add-on (iMacro) that automates filling in forms through a
script. I used that to get all of the NANPA dialing plan data. Here are
the discrepancies between the NANPA database and the local calling guide
database:


NANPA Data Local Calling Guide
NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
----------------------------------------------------------
204: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
274: 10D, 1+10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
327: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
415: 7D, 1+10D, 7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
447: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
464: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
557: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
564: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
615: 7D, 7D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
659: 10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
689: 10D, 10D, 1+10D, 1+10D - 7D, 1+10D, 1+10D, 1+10D
702: 10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
740: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
812: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
825: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 1+10D, 1+10D
843: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
975: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D


Ray Chow <czg7777@...>
 

NANPA is not necessarily internally consistent. What you see on LCG is from the NPA dialing plans report at http://nanpa.com/enas/npaDialingPlansReport.do

I have reloaded this since Chris did his query, so if NANPA is wrong, LCG will also be wrong ;)

The individual results Chris is pulling up from the area code search at http://nanpa.com/enas/npa_query.do are not always the same as the above, and the search has results for area codes that are not even in the dial plan report.



On Dec 14, 2014, at 9:22 PM, drew@... [local-calling-guide] <local-calling-guide@...> wrote:

I'm not necessarily saying that it's more accurate... just pondering
whether or not there might be some logic and reason to the differences.
NPA 740 just recently began 10D (Permissive), and that is not currently
reflected in the NANPA NPA Code Search system, but it is indicated as
standard in the local calling guide. I do not personally have knowledge
of how any of these systems are maintained, or how the data is
maintained, but that specific difference makes me wonder if someone or
something is updating the local calling guide records using some source
other than the NANPA NPA Code Search system. 

I also agree with your assumption that NANPA's dialplan data is "best
guess", or perhaps "desired state". In my experience, it is definitely
unsafe to rely upon that information when configuring CPE or
communicating to end users. 

On Sun, Dec 14, 2014, at 21:06, Chris Hodges nvideon@...
[local-calling-guide] wrote:
Thanks for the feedback Drew. Are you saying the local calling guide 
data may be more accurate? Czg7777@... indicated that the NANPA 
was the source of the local calling guide data.

I can only assume that NANPA data should be used only as a best guess as 
to how the actual plan is implemented. In Atlanta, AT&T (formerly Bell 
South) require all local calls to be dialed as 10D without the 1. It has 
been this way ever since Atlanta transitioned from one area code of 404 
and 7 digit local dialing to multiple area codes and 10D local dialing 
back in the 90's. However, the NANPA data indicates 1+10D is permitted 
for local dialing which is clearly wrong. There is no reason I know of 
that 404, 770, 678, and 470 area codes in and around Atlanta could not 
accept both 10 and 11 digit dialing for local calls. But I am not 
intimately familiar with the switching equipment they use, so perhaps 
there is a reasonable explanation.

On 12/13/2014 11:21 PM, drew@... [local-calling-guide] wrote:

Is it possible that all of these NPAs are currently transitioning from
one to the other, or are actually behaving differently in reality than
how NANPA describes that it should? For example, I see 740 on the below
list, and the difference between the two lists is LHNPA. Planning letter
471 indicates that the current state of 740 is 7D Standard and 10D
Permissive, but the NANPA NPA Code Search system indicates that 740 is
7D Standard and NA Permissive.

On Sat, Dec 13, 2014, at 19:34, nvideon@... [local-calling-guide]
wrote:
Firefox has an add-on (iMacro) that automates filling in forms through a
script. I used that to get all of the NANPA dialing plan data. Here are
the discrepancies between the NANPA database and the local calling guide
database:


NANPA Data Local Calling Guide
NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
----------------------------------------------------------
204: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
274: 10D, 1+10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
327: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
415: 7D, 1+10D, 7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
447: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
464: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
557: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
564: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
615: 7D, 7D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
659: 10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
689: 10D, 10D, 1+10D, 1+10D - 7D, 1+10D, 1+10D, 1+10D
702: 10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
740: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
812: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
825: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 1+10D, 1+10D
843: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
975: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D








------------------------------------
Posted by: drew@...
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
   http://groups.yahoo.com/group/local-calling-guide/

<*> Your email settings:
   Individual Email | Traditional

<*> To change settings online go to:
   http://groups.yahoo.com/group/local-calling-guide/join
   (Yahoo! ID required)

<*> To change settings via email:
   local-calling-guide-digest@... 
   local-calling-guide-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
   local-calling-guide-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
   https://info.yahoo.com/legal/us/yahoo/utos/terms/

Chris Hodges
 

Ray, thanks for the clarification. http://nanpa.com/enas/npaDialingPlansReport.do also reports that area codes in Atlanta have 1+10D permissive local dialing which they do not (as I reported below). It has been that way for about 20 years. So clearly the NANPA reports are not 100% accurate in either case.


On 12/14/2014 10:13 PM, Ray Chow czg7777@... [local-calling-guide] wrote:
�

NANPA is not necessarily internally consistent. What you see on LCG is from the NPA dialing plans report at�http://nanpa.com/enas/npaDialingPlansReport.do


I have reloaded this since Chris did his query, so if NANPA is wrong, LCG will also be wrong ;)

The individual results Chris is pulling up from the area code search at�http://nanpa.com/enas/npa_query.do�are not always the same as the above, and the search has results for area codes that are not even in the dial plan report.



On Dec 14, 2014, at 9:22 PM, drew@... [local-calling-guide] <local-calling-guide@...> wrote:

I'm not necessarily saying that it's more accurate... just pondering
whether or not there might be some logic and reason to the differences.
NPA 740 just recently began 10D (Permissive), and that is not currently
reflected in the NANPA NPA Code Search system, but it is indicated as
standard in the local calling guide. I do not personally have knowledge
of how any of these systems are maintained, or how the data is
maintained, but that specific difference makes me wonder if someone or
something is updating the local calling guide records using some source
other than the NANPA NPA Code Search system.�

I also agree with your assumption that NANPA's dialplan data is "best
guess", or perhaps "desired state". In my experience, it is definitely
unsafe to rely upon that information when configuring CPE or
communicating to end users.�

On Sun, Dec 14, 2014, at 21:06, Chris Hodges�nvideon@...
[local-calling-guide] wrote:
Thanks for the feedback Drew. Are you saying the local calling guide�
data may be more accurate? Czg7777@... indicated that the NANPA�
was the source of the local calling guide data.

I can only assume that NANPA data should be used only as a best guess as�
to how the actual plan is implemented. In Atlanta, AT&T (formerly Bell�
South) require all local calls to be dialed as 10D without the 1. It has�
been this way ever since Atlanta transitioned from one area code of 404�
and 7 digit local dialing to multiple area codes and 10D local dialing�
back in the 90's. However, the NANPA data indicates 1+10D is permitted�
for local dialing which is clearly wrong. There is no reason I know of�
that 404, 770, 678, and 470 area codes in and around Atlanta could not�
accept both 10 and 11 digit dialing for local calls. But I am not�
intimately familiar with the switching equipment they use, so perhaps�
there is a reasonable explanation.

On 12/13/2014 11:21 PM, drew@... [local-calling-guide] wrote:

Is it possible that all of these NPAs are currently transitioning from
one to the other, or are actually behaving differently in reality than
how NANPA describes that it should? For example, I see 740 on the below
list, and the difference between the two lists is LHNPA. Planning letter
471 indicates that the current state of 740 is 7D Standard and 10D
Permissive, but the NANPA NPA Code Search system indicates that 740 is
7D Standard and NA Permissive.

On Sat, Dec 13, 2014, at 19:34, nvideon@... [local-calling-guide]
wrote:
Firefox has an add-on (iMacro) that automates filling in forms through a
script. I used that to get all of the NANPA dialing plan data. Here are
the discrepancies between the NANPA database and the local calling guide
database:


NANPA Data Local Calling Guide
NPA: LHNPA, THNPA, LFNPA, TFNPA - LHNPA, THNPA, LFNPA, TFNPA
----------------------------------------------------------
204: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
274: 10D, 1+10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
327: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
415: 7D, 1+10D, 7D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
447: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
464: 1+10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
557: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D
564: 10D, 10D, 1+10D, 1+10D - 7D, 10D, 1+10D, 1+10D
615: 7D, 7D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
659: 10D, 1+10D, 1+10D, 1+10D - 1+10D, 1+10D, 1+10D, 1+10D
689: 10D, 10D, 1+10D, 1+10D - 7D, 1+10D, 1+10D, 1+10D
702: 10D, 1+10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
740: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
812: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
825: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 1+10D, 1+10D
843: 7D, 10D, 1+10D, 1+10D - 10D, 10D, 1+10D, 1+10D
975: 10D, 10D, 1+10D, 1+10D - 10D, 1+10D, 10D, 1+10D








------------------------------------
Posted by:�drew@...
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
���http://groups.yahoo.com/group/local-calling-guide/

<*> Your email settings:
���Individual Email | Traditional

<*> To change settings online go to:
���http://groups.yahoo.com/group/local-calling-guide/join
���(Yahoo! ID required)

<*> To change settings via email:
���local-calling-guide-digest@...�
���local-calling-guide-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
���local-calling-guide-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
���https://info.yahoo.com/legal/us/yahoo/utos/terms/