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