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 <[email protected]> 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 >> [email protected] | 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 <[email protected]> on behalf of Mike Hammett >> <[email protected]> >> Sent: Thursday, January 23, 2020 11:42 AM >> To: voiceops <[email protected]> >> 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 >> [email protected] >> https://puck.nether.net/mailman/listinfo/voiceops >> >> >> _______________________________________________ >> VoiceOps mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/voiceops > > -- > Glen Gerhard > [email protected] > 858.324.4536 > > Cognexus, LLC > 7891 Avenida Kirjah > San Diego, CA 92037 > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
