[Asterisk-Users] Semi-OT: porting numbers away

Rich Adamson radamson at routers.com
Fri Dec 30 09:19:45 MST 2005


> Thanks, but I'm looking for information on porting numbers when the current
> provider holding the numbers goes out of business and is unreachable.  Can I
> get the numbers?  The business has had the same phone number for almost 30
> years and definitely can't lose the number due to some provider's
> instability.
> As most VoIP companies are relatively new and small, I'm a bit skittish
> about porting these numbers to an ITSN, then that company going out of
> business and not being able to get my numbers back.  How would that work?

Let's see if I can clearify this a little bit.

Local Number Portability (LPN) is a little different for telco's then it
is for cell phone providers, with far more politics involved in the telco
implementation.

On the telco side, the local telco provider (owner of the telephone number
to be moved) has to initiate the move since they "own" the NPA-NNX number.
They have to do "something" in their central office switch so that local
callers to that number are routed to some other facility as opposed to
another "line" in their switch. They also have to enter the change in a
database that is accessible via the nationwide SS7 network, so distant
callers to that number are routed to the appropriate central office.

The owners of the NPA-NNX number is important from the standpoint they are
supposed to be the only people with "permissions" to make SS7 database
entry changes for their NPA-NNX numbers.

The remote "appropriate central office" has to do something in their central
office switch to map that new telephone number to a "line" (not another
telephone number).

So in the above simple example, it takes changes to two telco switches and
one national database to complete the move. Keep in mind the owners of the
database only allow changes to that specific number-to-be-moved to come
from the owner of the NPA-NNX number. If the customer decides to discontinue
service (drop the moved telephone number), it is the responsibility of the
remote appropriate central office to notify the owner of the NPA-NNX, and
that owner initiates the local changes and database changes to bring that
number back into their home switch.

The political part of that involves questions such as "should a customer
in the 123-456 central office calling a portable number such as 345-678
that is in the exact same central office be invoiced as a toll call?"
Both the state public service commissions and the FCC have been involved
with those discussions, and there has not been any formal ruling that would
clearify all the questions. Therefore, many of the local exchange carriers
refuse to allow LNP as a result of these unanswered questions, and have been
getting by with it for well over a year.

Now, take the above example and change it so the portable number ends up at
a distant itsp. The exact same steps noted above have to be completed, but
in addition, the remote appropriate central office "generally" have to map
that moved number to another telephone number (most likely a DID number)
that is assigned to the itsp. This last step is very similar to how 800
numbers are handled by the local telephone companies now. The group that
is responsible for that mapping is generally the remote appropriate central
office.

So, now you have two steps required at the owning NPA-NNX central office,
and two steps at the receiving central office, and at least one final step
by the itsp (mapping the DID to a sip/iax customer).

Now to answer the original qustion: to move that same number to yet another
itsp requires the telco at the remote receiving central office to "unmap"
the local itsp DID map, and if the new mapping is to a different itsp that
is still in the same local area, remap the LNP number to the new itsp.

If the itsp is at some distant unrelated central office, the remote central
office has to unmap the original number, remove entries from their central
office switch, and update the national SS7 database to point the entry to
the next new central office. Then that next new central office has to 
create entries in their central office switch and possibly map that number
to some itsp DID number.

If all of that seems confusing, it is. But, you can begin to see who is
responsible for what, and how well the above steps work is highly dependent
on how well itsp technical folks communicate with telco technical folks in
each geographic area. Pile on top of that the requirement by most telcos
that no technical work will be performed without an accurate service order,
and you have the makings of a rather serious problem. (Try explaining all 
that to the telco folks that are responsible for originating the service 
order, and you have a bigger problem since those folks are not technical 
at all.)

Can it be done? Yes, but there is a very high probability of errors and
likely some degree of refusing to "own" the process through to completion.

Moving cell numbers from one provider to another is less of an issue primarily
because there are a lot less political issues to be raised. E.g., there are
no concerns over who bills for toll calls as most cell phone plans have
all that built in regardless of where you call.

If one moved a KC pstn number to DC, and then later tried to move that same
number to NYC, who is responsible for the first move and who is responsible
for the second move? (Should be able to figure that out from the above, and
knowing the answers to the first verses second move will make the move
happen with far less errors and/or issues.)

FWIW, I know of a small local Siemens central office where the owners refuse
to allow LNP. Part of the reason for their refusal is that for their switch,
they would have to purchase another database server from Siemens (which is
rather expensive) to actually implement LNP. Another part of their refusal
is they have never received a "properly formated" request from a customer
and the public service commission has supported their refusal (at least for
now).





More information about the asterisk-users mailing list