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.chukalovs...@gmail.com>
Sent: Thursday, January 23, 2020 12:57pm
To: "Glen Gerhard" <g...@cognexus.net>
Cc: voiceops@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 <[ g...@cognexus.net ](
mailto:g...@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
[ myak...@firstlight.net ]( mailto:myak...@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-boun...@voiceops.org> ](
mailto:voiceops-boun...@voiceops.org ) on behalf of Mike Hammett [
<voice...@ics-il.net> ]( mailto:voice...@ics-il.net )
Sent: Thursday, January 23, 2020 11:42 AM
To: voiceops [ <voiceops@voiceops.org> ]( mailto:voiceops@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@voiceops.org ]( mailto:VoiceOps@voiceops.org )
[ https://puck.nether.net/mailman/listinfo/voiceops ](
https://puck.nether.net/mailman/listinfo/voiceops )
_______________________________________________VoiceOps mailing list[
VoiceOps@voiceops.org ]( mailto:VoiceOps@voiceops.org )[
https://puck.nether.net/mailman/listinfo/voiceops ](
https://puck.nether.net/mailman/listinfo/voiceops )
-- Glen Gerhard[ g...@cognexus.net ]( mailto:g...@cognexus.net
)858.324.4536Cognexus, LLC7891 Avenida KirjahSan Diego, CA 92037
_______________________________________________
VoiceOps mailing list
[ VoiceOps@voiceops.org ]( mailto:VoiceOps@voiceops.org )
[ https://puck.nether.net/mailman/listinfo/voiceops ](
https://puck.nether.net/mailman/listinfo/voiceops )
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
