No, it won't. The rejections the other side provides are largely
optional, and in fact the FCC has issued strict guidance about the
necessary level of matching on an LSR (I want to say it's telephone
number, account number, PIN if applicable, and zipcode, but I know
there's some conditional variations on this).
Making the customer request a code from their losing carrier violates
(at least the spirit, if not the letter of) current regulations by
giving the current carrier a chance to market to an existing customer,
threaten them, or make them pay a fee or contract termination price up
front to get the code, or create undue levels of complexity on getting
the code.
Currently, you can create subscriptions against a number and force the
issue, porting the number under hostile conditions is in fact
technically possible (in fact, i've done it before, with a service
provider placing a large quantity of numbers in conflict over a
unrelated dispute, conflict expiration window can be your friend if you
use it carefully). The only person who can complain about it is the
customer themselves as long as the numbers are active, so if they're on
your side and you're certain the number is active, the losing carrier
has little recourse. Adding a step where your ability to port relies on
the good graces of the losing carrier is going to create a far worse
situation.
-Paul
On 12/07/2015 11:06 AM, Peter Beckman wrote:
I hadn't heard of Iconectiv (one "n") before. I found this:
http://www.ericsson.com/news/150326-fcc-authorizes-local-number-portability_244069647_c
Was it Neustar prior to this change?
I dream of a process for LNP that goes like this:
1. Customer goes to current carrier, requests a Porting Authorization
Code for a number (or set of numbers), either online or over
the phone.
2. Current carrier generates a Porting Authorization Code and
provides
it to the Customer.
3. Customer goes to new carrier, provides Phone Number, Current
Carrier, and the Porting Authorization Code.
4. New carrier submits port request to Current Carrer with the Number
and Porting Authorization Code. No name, billing address, PIN/SSN,
just those three things.
5. Current carrier matches the Porting Authorization Code with their
records for that Number and the port goes through.
Since all of this is centralized, just have Iconectiv manage it -- the
Current Carrier uses an API with Iconectiv to register the number and
get a
code back. The New Carrier uses the API with Iconectiv with the number
and
the code to verify porting. Codes expire after x days.
Will Iconectiv bring this level of sanity to porting in the NANP? Or will
it be more of the same, with rejections for an incorrect street
abbreviation?
I know it's more complicated than that to implement, but it really
ticks me
off how difficult it is to port numbers these days if you aren't a Tier 1
wireless carrier.
Beckman
On Sat, 5 Dec 2015, Erik Flournoy wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the
traditional
PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be
administering
the LNP in the US I feel as though it's the best time to try and propose
new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in
NPAC,
but there is a monthly charge for the remote access to the NPAC. Then
the
interconnectivity at the LEC level. The archaic ways of telecom have not
seemed to change much although VOIP is now in my opinion the standard of
telecom. VOIP will soon be able to get code blocks and route via SIP
vs SS7
and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing
company.
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
