Date   
Re: Mobile number portability

czg7777
 

You quoted a Wikipedia article, which goes on to mention that:

...
Numbers are only portable within a LIR (local interconnection region), regions defined by the ILEC and approved by the Canadian Radio-television and Telecommunications Commission (CRTC), each of which cover a number of exchanges. Each LIR has a Point of Interconnection (POI) exchange through which calls are routed, and if a number is ported out to a different LIR then calls to that destination will be rejected by the POI switch.
Not all exchanges support LNP, typically there needs to exist competition within an exchange before an ILEC will enable portability, and then only by request. Most small local independent telephone company exchanges are exempted from competition and local number portability requirements. Numbers in the rarely used non-geographic area code 600 are not portable.

Local interconnection regions follow ILEC switching arrangements, and typically cover relatively small areas. See https://localcallingguide.com/lca_listlir.php for a list.



On Dec 23, 2018, at 11:02 AM, belanger@... wrote:

My question was in reference to the definition on telephone portability. See below. It could be that I misinterpret the part on geographic portability.

As czg7777 mentioned, landline caller have long distance reaching me on my cell phone. So I thought that if geographic portability is provided by some means I could request my cell phone number to be moved to the city where I actually live?

Local number portability (LNP) for fixed lines, and full mobile number portability (FMNP) for mobile phone lines, refers to the ability of a "customer of record" of an existing fixed-line or mobile telephone number assigned by a local exchange carrier (LEC) to reassign the number to another carrier ("service provider portability"), move it to another location ("geographic portability"), or change the type of service ("service portability").[1] 

Problems retrieving details programatically

John Nevius
 

All,

I've been successfully running, since about 2014, a python program to derive the local calling area for NANPA rate centers.  This is done through a python program that posts the XML string:
(where the npa and nxx values are inserted into the string for the %s

This works successfully for multiple queries but then fails on a query that should be valid.  e.g.

. . . . . processing RC JERSEYCITY, NJ in LATA 224
. . . . . processing RC HACKENSACK, NJ in LATA 224
. . . . . processing RC NEWARK, NJ in LATA 224
. . . . . processing RC UNION CITY, NJ in LATA 224
. . . . . processing RC MORRISTOWN, NJ in LATA 224
. . . . . processing RC BAYONNE, NJ in LATA 224
. . . . . processing RC CLIFFSIDE, NJ in LATA 224
. . . . . processing RC ORADELL, NJ in LATA 224
. . . . . processing RC ENGLEWOOD, NJ in LATA 224
. . . . . processing RC LEONIA, NJ in LATA 224
. . . . . processing RC SUCCASUNNA, NJ in LATA 224

For the last query (NPANXX = 201230) all I get is:
<Response [200]>

This problem is repeated multiple times, sometimes on consecutive queries sometimes after multiple successful queries

This problem is repeatable.  I've tried inserting a short (1 second) pause before I make each query, with no apparent difference.  

Has anyone seen this or have a suggested work-around?

Re: Problems retrieving details programatically

Wahl, James R.
 

I'm having similar issues. Did you ever get it resolved?

Re: Problems retrieving details programatically

Jeremy Schaeffer
 


Sort of. They changed to https only, I never got the time to re-write my java to do https, its a lot more complicated. You have to deal with ssl. - Jeremy

On 7/23/2019 9:47 AM, Wahl, James R. wrote:
I'm having similar issues. Did you ever get it resolved?