[VoiceOps] Post-Port Activation Delay

Thu Jan 23 13:12:13 EST 2020

Our local cable operator does that -- only updates their subscriber info in their switch once a day.  So, if you port in the morning, people using their switch won't be able to call the new customer until the next day.

-----Original Message-----
From: "Victor C" <victor.chukalovskiy at gmail.com>
Sent: Thursday, January 23, 2020 12:57pm
To: "Glen Gerhard" <glen at cognexus.net>
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Post-Port Activation Delay

Based on how things work in Canada, but should not be much different for you. Two common scenarios:
Often class 4/5 switches or STPs are configured to cache LRN records either for X number of minutes or hours. Thus reducing number of dips it has to make. I think of it like dns caching. When particular record expires it would dip again. X would differ by carrier, so you cant tell for sure and cant fix that other than wait
Sometimes a  number is not removed from a local switch it used to be programmed in. So even after LRN is changed, other ppl in that same switch will hit the old / disconnected line. But all other callers will reach you no problem. This is because older switches do local subscriber lookup before doing LRN dip... so if there is a bogus local record it will win over anything LRN related. This issue would be isolated to single switch / single carrier and wont resolve by itself until someone removes the number programming.

On Jan 23, 2020, at 12:45, Glen Gerhard <[ glen at cognexus.net ]( mailto:glen at cognexus.net )> wrote:

I would expect that mobile providers would have up to date porting information, regardless of how you initiate the port.

 Apparently the some of the ones you tested on use a nightly update, so as Matt said, you will just have to wait.

 ~Glen

On 1/23/2020 8:55, Matthew Yaklin wrote:
Isn't this a case of the "sloppy" providers using a LNP cache system on their switch and you simply have to wait for it to expire out for each number? Once it expires they will redip for the proper LRN and calls flow normally...
I guess it happens to me but I simply ignore it.. it will fix itself. I normally do ports in the evening and that way we have a solid 12 plus hours before they open the next morning.
Or did I misread the question and gave a terrible answer?
Matt

Matthew Yaklin
Network Engineer
FirstLight
359 Corporate Drive │ Portsmouth, NH 03801
Mobile 603-845-5031
[ myaklin at firstlight.net ]( mailto:myaklin at firstlight.net ) | [ www.firstlight.net ]( http://www.firstlight.net )
This email may contain FirstLight confidential and/or privileged information. If you are not the intended recipient, you are directed
not to read, disclose or otherwise use this transmission and to immediately delete same. Delivery of this message is not intended
to waive any applicable privileges.
From: VoiceOps [ <voiceops-bounces at voiceops.org> ]( mailto:voiceops-bounces at voiceops.org ) on behalf of Mike Hammett [ <voiceops at ics-il.net> ]( mailto:voiceops at ics-il.net )
Sent: Thursday, January 23, 2020 11:42 AM
To: voiceops [ <voiceops at voiceops.org> ]( mailto:voiceops at voiceops.org )
Subject: [VoiceOps] Post-Port Activation Delay

I would like to preface this email by saying that I know that iconnectiv is managing ports now, but we just have the old Neustar portal working as the front end because I haven't had time to learn how all this stuff works so that I can properly train our employees on how to use the new portal.

 Undo business. Our people that manage the porting currently go into the neustar portal and activate a port. At that time, some carriers immediately start using bus. However, some carriers will still send traffic to the losing provider for some amount of time after that. Sometimes that is okay, sometimes it is not. I assume that there is not a darn thing that I can do about how quickly someone else decides to look up the number to see that it has been ported.

 However, can someone explain to me how common this is and what providers arnone for being sloppy? For example, last night we did a port at 9 pm. A test call that we did to a forwarding number that would have bounced through AT&T ILEC went through fine every time. Calls that would have gone through a variety of cell providers was extremely Hit or Miss, Even from the same operator.

 I apologize for any misused words. I was using voice to text and editing that on my phone can be difficult.

 -----
 Mike Hammett
 Intelligent Computing Solutions
[ http://www.ics-il.com ]( http://www.ics-il.com )

 Midwest Internet Exchange
[ http://www.midwest-ix.com ]( http://www.midwest-ix.com )

 _______________________________________________
 VoiceOps mailing list
[ VoiceOps at voiceops.org ]( mailto:VoiceOps at voiceops.org )
[ https://puck.nether.net/mailman/listinfo/voiceops ]( https://puck.nether.net/mailman/listinfo/voiceops )

_______________________________________________VoiceOps mailing list[ VoiceOps at voiceops.org ]( mailto:VoiceOps at voiceops.org )[ https://puck.nether.net/mailman/listinfo/voiceops ]( https://puck.nether.net/mailman/listinfo/voiceops )

-- Glen Gerhard[ glen at cognexus.net ]( mailto:glen at cognexus.net )858.324.4536Cognexus, LLC7891 Avenida KirjahSan Diego, CA 92037
_______________________________________________
VoiceOps mailing list
[ VoiceOps at voiceops.org ]( mailto:VoiceOps at voiceops.org )
[ https://puck.nether.net/mailman/listinfo/voiceops ]( https://puck.nether.net/mailman/listinfo/voiceops )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20200123/5c778c12/attachment.htm>