+1 On Thu, Aug 30, 2018 at 08:04:06AM -0500, Adam Vocks wrote:
> Hi Mike, if you have money to throw at the problem, I think I'd just > hire Mary to track down and fix the problem for you. She's obviously > knowledgeable, probably has enough contacts and is now familiar with > your problem. > > Adam > > -----Original Message----- > From: VoiceOps [mailto:[email protected]] On Behalf Of Mike > Hammett > Sent: Thursday, August 30, 2018 7:17 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [VoiceOps] LNP, tandems, etc. > > 1) How do I find an appropriate contact to ask? > 2) From what Mary has said, Comcast is doing it wrong in my area. I > suppose it's useful to know how something is SUPPOSED to be done and > acknowledge that it very well could be very different in production. > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > > > Midwest Internet Exchange > http://www.midwest-ix.com > > > > ----- Original Message ----- > From: [email protected] > To: [email protected], [email protected], > [email protected] > Cc: [email protected], [email protected] > Sent: Wed, 29 Aug 2018 21:04:33 -0500 (CDT) > Subject: Re: [VoiceOps] LNP, tandems, etc. > > <div dir="auto">The block owner often has a connection to the ILEC > tandem for their block in that range, but that's not always > necessary (I don't have any ilec FGD groups in the Chicago LATA, so > it's not universally necessary).<div dir="auto"><br></div><div > dir="auto">The only way to know for certain is to check the LERG or just > ask the carrier, which is what I usually do because I don't like > giving money to iconnectiv, since they tend to like to send me legally > cartoonish Cease and Descists every few years for the last > decade.</div></div><div class="gmail_extra"><br><div > class="gmail_quote">On Aug 29, 2018 21:49, Mike Hammett > <[email protected]> wrote:<br><blockquote><html><head><style>p { > margin: 0; }</style></head><body><div style="font-family: > arial,helvetica,sans-serif; font-size: 10pt; color: #000000">So then in > my situation: > https://www.telcodata.us/search-area-code-exchange-detail?npa=815&; > amp;exchange=901<br><br><br>Comcast has 815-901 as > well as > 815-901-0. Verizon Wireless has 1k-8k. 9k I guess would be either not > provisioned or default back to Comcast because they have the 10k block. > Because they have the parent 10k block, are they then required to have a > connection to the tandem I'm on anyway? The 1k block I now > understand could be elsewhere, but the 10k?<br><br>Interesting that > AT&T U-Verse voice isn't on legacy AT&T > infrastructure.<br><br><div><span></span><br><br>-----<br>Mike > Hammett<br>Intelligent Computing > Solutions<br>http://www.ics-il.com<br><br><br><br>Midwest Internet > Exchange<br>http://www.midwest-ix.com<br><br><span></span><br></div><br> > <hr id="zwchr"><div > style="color:#000;font-weight:normal;font-style:normal;text-decoration:n > one;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: > </b>[email protected]<br><b>To: </b>[email protected], > [email protected], [email protected]<br><b>Cc: > </b>[email protected], [email protected]<br><b>Sent: > </b>Wednesday, > August > 29, 2018 7:08:15 PM<br><b>Subject: </b>Re: [VoiceOps] LNP, tandems, > etc.<br><br><div dir="auto">Thousands blocks are basically just a fancy > LNP operation. Your tandem homing has to follow 10k blocks, and the 1k > blocks are basically mass ported to your LRN. Even if the numbers are > usually homed a certain way because they are in a ratecenter, they > won't be in this case because they are ported numbers and supposed > to be routed to your LRN. Example would be the Detroit LATA where there > are about 6 or so AT&T and other tandems. I'm homed off > WBFDMIMN20T. The local carrier has local/local toll trunks to me all > over the place, but all intercarrier calls and out of area calls other > than local traffic from AT&T LEC comes through my LRN 248-574-7678 > off WBFDMIMN20T. This saves me from having to create FGD trunking ports > to all the other tandems in the region, only the barely used local/intra > trunking from AT&T ILEC, who has moved most customers to their > uverse VoIP > affilia > te here, and those don't use the local/intra trunks either.<div > dir="auto"><br></div><div dir="auto">It lowers my capex and opex having > potentially over provisioned/underutilized trunking all over the place, > saves numbers and decreases the need for splits and overlays, and even > saves at&t money. Only people who lose out are ribbon and metaswitch > (and whoever supports at&ts 5ESS and EWSD deployments) on licensing > and support costs for unneeded channels.</div></div><div > class="gmail_extra"><br><div class="gmail_quote">On Aug 29, 2018 19:51, > Mike Hammett <[email protected]> wrote:<br><blockquote><style>p > { margin: 0; }</style><div style="font-family: > arial,helvetica,sans-serif; font-size: 10pt; color: #000000"><font > face="arial, helvetica, sans-serif"><span style="font-size: > 10pt;">"</span></font><span style="font-family: "Times New > Roman"; font-size: medium; background-color: rgb(255, 255, > 255);">they give you market entry without the technic > al need > to establish extra homing arrangements that aren't beneficial to > you."</span><div><br></div><div>Could you elaborate on > that?<br><br><div style="font-family: arial, helvetica, sans-serif; > font-size: 10pt;"><span></span><br><br>-----<br>Mike > Hammett<br>Intelligent Computing > Solutions<br>http://www.ics-il.com<br><br><br><br>Midwest Internet > Exchange<br>http://www.midwest-ix.com<br><br><span></span><br></div><br> > <hr id="zwchr" style="font-family: arial, helvetica, sans-serif; > font-size: 10pt;"><div style="font-family: Helvetica, Arial, sans-serif; > font-size: 12pt; color: rgb(0, 0, 0); font-weight: normal; font-style: > normal; text-decoration: none;"><b>From: </b>[email protected]<br><b>To: > </b>[email protected], [email protected], > [email protected]<br><b>Cc: </b>[email protected], > [email protected]<br><b>Sent: </b>Wednesday, August 29, 2018 > 6:05:39 PM<br><b>Subject: </b>Re: [VoiceOps] LNP, tandems, > etc.<br><br><div dir="auto">I've had some i > nteresti > ng arguments with other carriers regarding their obligation to connect > to us. Oh, you aren't connected where I'm homed? Go order > connectivity then.<div dir="auto"><br></div><div dir="auto">They have a > little more power to make demands when you have more than 24 standing > calls to them, but by and large with these stubborn providers we never > do, and when they have complained i've given them a location they > can install 1 way trunks to me at (as I have no desire to terminate > traffic to them directly), and they always balk and find some other way > of dealing with it because it was all well and good until it was their > money they were spending instead of mine. The trick ends up being to > never do 10k blocks when you don't have to. Thousands blocks > aren't just great for number consolidation, they give you market > entry without the technical need to establish extra homing arrangements > that aren't beneficial to you. Sure sometimes you're the guy who > has to own > the 10k > block, bu<blockquote><p>That's true if the ILEC has an agreement > with the tandem provider. There > are some little ILECs that have their own tandem and refuse to use the > big ILEC tandem provider! You have to look at the routing of the ILEC > switch in the LERG to figure that out. > > Mary Lou Carey > > BackUP Telecom Consulting > > Office: 615-771-7868 (temporary) > > Cell: 615-796-1111 > > On 2018-08-29 11:38 AM, Paul Timmins wrote: > > You don't actually have to establish connectivity to all ILECs > in an > > area, even if you are porting out numbers from their ratecenters. > The > > ILECs already have to have a way to reach any other tandem in the > LATA > > so as long as you have an LRN homed on A tandem in the area, and > port > > your numbers to that, you're good to go. > > > > The ILECs don't LIKE it, but if we cared what they truly liked > we'd > > all just leave the market. > > > > On Aug 29, 2018 12:33, BackUP Telecom Consulting > > wrote: > > > > When there are multiple ILECs in a LATA like in LA - LATA 730, you > > would > > set up an interconnection point with each ILEC. So you'd have > one for > > the AT&T areas and one for the old Verizon areas. When you have > trunks > > > > to both carriers in the LATA, you can use your own network to > switch > > traffic from the one LATA to the other LATA, but you can't > deliver it > > to > > the ILEC and expect them to hand it off to the other ILEC. It would > > work > > the same with the third party providers.......as long as they have > a > > connection in both ILEC areas, then they can use their own network > to > > deliver the traffic from the one ILEC area to the other ILEC area. > > > > Mary Lou Carey > > > > BackUP Telecom Consulting > > > > Office: 615-771-7868 (temporary) > > > > Cell: 615-796-1111 > > > > On 2018-08-28 08:18 PM, Mike Hammett wrote: > >> I thought everyone connected to the ILEC-hosted tandem > responsible > > for > >> the rate centers where the number blocks were assigned, but > that > > seems > >> to not always be the case when there are multiple ILEC-hosted > > tandems > >> in a LATA. > >> > >> ----- > >> Mike Hammett > >> Intelligent Computing Solutions > >> http://www.ics-il.com > >> > >> Midwest Internet Exchange > >> http://www.midwest-ix.com > >> > >> ------------------------- > >> > >> FROM: "Erik" > >> TO: "Mike Hammett" > >> CC: [email protected] > >> SENT: Tuesday, August 28, 2018 7:25:40 PM > >> SUBJECT: Re: [VoiceOps] LNP, tandems, etc. > >> > >> Most providers simply connect to the tandem at the ILEC. The > end > >> office transit termination and origination cost is SO LOW that > it > >> doesn't make since to have a switch or access point at the > end > > office. > >> Since most things are ILEC if not all are VOIP everything is > coming > >> from a centralize switch point. Hopefully all the 1970's > billing > >> methods will disappear. > >> > >> On Tue, Aug 28, 2018 at 1:00 PM, Mike Hammett > >> wrote: > >> > >>> Meaning if I thought were true? I had just assumed that > Inteliquent > >>> did have the connections to every tandem in the LATAs they > serve, > >>> given that (my thought) that you could only port numbers on > the > > same > >>> tandem, so universal coverage would require connections to > every > >>> tandem. We're actually looking at someone like > Inteliquent to > > expand > >>> our footprint. > >>> > >>> So I'm supposed to be connected to every tandem in my > LATA? In my > >>> LATA, there are only two (I believe), but some LATAs (like > Chicago) > >>> have several. I'm supposed to drag a DS1 (or use > Inteliquent, etc. > >>> if available) to connect to each one, even if I don't > provide > >>> service in the rate centers traditionally served by that > tandem? It > >>> seems like Comcast threw a dart at a dart board in choosing > which > >>> tandem to connect to vs. going with the one that everyone > else in > >>> that town uses. > >>> > >>> So then I could port a number from any rate center in my > LATA (say > >>> Savanna) and point it to my LRN, living off of a tandem > switch that > >>> the Savanna ILEC isn't connected to (from my outside > world > >>> perspective)? Is there even the LATA constraint? Given the > porting > >>> limitations I had experienced in the VoIP world, I assumed > it was a > >>> tandem-by-tandem basis. > >>> > >>> So the LERG shows which tandem I need to send traffic to if > I want > >>> to talk to them, but they could send their outbound calls > to a > >>> different tandem? My current customer complaint is for > calls that > >>> we're sending to Comcast, apparently homed off of the > other tandem. > >>> > >>> If everyone is supposed to be on every tandem, then why > can't the > >>> tandem I'm on just accept the calls I'm sending to > Comcast, since > >>> Comcast should be there? Obviously me not being on the > other tandem > >>> would affect inbound traffic to me. > >>> > >>> Is there another service I should be paying Frontier for to > get me > >>> to the other tandem with some value-add service? I know > CenturyLink > >>> hops through almost every town going that way (former > LightCore and > >>> others before route). Frontier or CenturyLink may be able > to get me > >>> a DS1 to the other tandem if I need that. > >>> > >>> I'm aware that I could still be completely missing the > mark. > >>> > >>> BTW: Thanks for TelcoData. I subscribed a long time ago, > but > > haven't > >>> for many ages. > >>> > >>> ----- > >>> Mike Hammett > >>> Intelligent Computing Solutions > >>> http://www.ics-il.com > >>> > >>> Midwest Internet Exchange > >>> http://www.midwest-ix.com > >>> > >>> ------------------------- > >>> > >>> FROM: "Paul Timmins" > >>> TO: "Mike Hammett" > >>> CC: [email protected] > >>> SENT: Tuesday, August 28, 2018 5:19:11 PM > >>> SUBJECT: Re: [VoiceOps] LNP, tandems, etc. > >>> > >>> If that were true, you wouldn't be able to use > inteliquent (et al) > >>> as your access tandem. Everyone is supposed to be directly > or > >>> indirectly connected to every tandem in the LATA (which you > can't > >>> independently verify, as telcodata and the LERG both show > >>> terminating tandem information to reach that end office, > not what > >>> tandems the end office is hooked to to terminate calls. > >>> > >>> On Aug 28, 2018 17:47, Mike Hammett wrote: > >>> > >>> I thought you had to be on the same tandem to port a > number, but > >>> with what our tandem operator (Frontier) is telling me, > this isn't > >>> the case. > >>> > >>> Comcast ported a number from us in town A. The LRN they > pointed to > >>> is based in town B (per TelcoData). The tandem generally > used by > >>> carriers in both towns is based in town B. Naturally, we > send > >>> traffic to that tandem. > >>> > >>> The operator of that tandem is telling us that the LRN is > actually > >>> homed off of a different tandem in our LATA (operated by > >>> CenturyLink) in town C. Unfortunately, I can't > corroborate this > >>> information with TelcoData the only rate center I see off > of that > >>> tandem in TelcoData is an AT&T town next door. > >>> > >>> Where can I read up authoritatively on the porting > requirements > > that > >>> would apply to this and related bits of info I should know? > >>> > >>> I'm checking on our LERG access as I know that has the > > authoritative > >>> information, but I don't have that access at the > moment. Maybe > > we're > >>> not subscribed to it. > >>> > >>> Number NPA-NXX in town A: > >>> > >> > > > https://www.telcodata.us/search-area-code-exchange-detail?npa=815&ex > change=991 > > [1] > >>> > >>> LRN NPA-NXX in town B: > >>> > >> > > > https://www.telcodata.us/search-area-code-exchange-detail?npa=815&ex > change=901 > > [2] > >>> > >>> Tandem in town B: > >>> > >> > > > https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DKLBILX > A50T > > [3] > >>> Tandem in town C: > >>> > >> > > > https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DIXNILX > A50T > > [4] > >>> > >>> Thanks. > >>> > >>> ----- > >>> 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 > > _______________________________________________ > > VoiceOps mailing list > > [email protected] > > https://puck.nether.net/mailman/listinfo/voiceops > > > > > > Links: > > ------ > > [1] > > > https://www.telcodata.us/search-area-code-exchange-detail?npa=815&ex > change=991 > > [2] > > > https://www.telcodata.us/search-area-code-exchange-detail?npa=815&ex > change=901 > > [3] > > > https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DKLBILX > A50T > > [4] > > > https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DIXNILX > A50T > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > </p></blockquote><br>_______________________________________________<br> > VoiceOps mailing > list<br>[email protected]<br>https://puck.nether.net/mailman/listinf > o/voiceops<br></div><br></div></div></div></div> > </blockquote></div><br></div></div></div></body></html> > </blockquote></body></html> > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
