[VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

Paul Timmins paul at timmins.net
Mon Dec 7 12:10:32 EST 2015

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 


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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20151207/45c52d51/attachment.html>

More information about the VoiceOps mailing list