[VoiceOps] Post-Port Activation Delay

[Victor C]

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> 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 | 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> on behalf of Mike Hammett <voiceops at ics-il.net>
>> Sent: Thursday, January 23, 2020 11:42 AM
>> To: voiceops <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
>> 
>> 
>> 
>> Midwest Internet Exchange
>> http://www.midwest-ix.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
> 
> -- 
> Glen Gerhard
> glen at cognexus.net
> 858.324.4536
> 
> Cognexus, LLC
> 7891 Avenida Kirjah
> San Diego, CA 92037
> _______________________________________________
> 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/20200123/0c349b73/attachment-0001.htm>