[VoiceOps] Connecting to Remote Tandems

[Paul Timmins]

I'm sure I know which one you're talking about. It's because they exist 
in entirely different regulatory domains. The upside of inbound feature 
group D is that you get to cut out a terrible ILEC tandem, and at least 
the vendor I'm thinking of doesn't charge for the trunks themselves, so 
you're at a very strong cost advantage on it.

Inbound local trunking, usually interconnection agreements dictate that 
the trunks have to be dedicated per carrier, so you're just avoiding 
sinking hardware cost and transport, but it still uses up considerable 
resources at least in AT&T areas. So if you need 3 trunks to CHCGILWB's 
tandem, they can't just route that to their trunks where they have 
existing capacity, like FGD, but they have to install 3 shiny new T1s 
just for your traffic, that they order as you, to their equipment. It's 
stupid, convoluted, and wasteful but it's not the vendor's fault, it's 
AT&T maintaining artificial barriers to competition. As if they'd have 
it any other way.

-Paul

On 8/9/19 3:42 PM, Mike Hammett wrote:
> I'm evaluating methods of extending our footprint. I purposely left 
> out company names.
>
> One of the companies we talked to was really only interested in 
> getting us the inbound long distance calls, not the local ones. Well, 
> they would, but the terms were vastly different.
>
> Given that I still need to build out to connect to the local tandem, 
> what's the point in using a third party to connect to long distance?
>
> Are the terms for connecting to the local tandems different because 
> the access tandem is simpler, whereas the local tandem could 
> potentially involve connections to a bunch of other switches, once 
> volume dictated I needed direct connections...  and they don't want to 
> deal with that?
>
> Are there third parties that don't have vastly different terms for 
> local tandem services?
>
> Also, is it likely that I just don't understand what's going on? I 
> went circles with the sales rep to make sure I understood what he was 
> saying, but I could be wrong.
>
>
>
> -----
> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20190809/9e8500b6/attachment.htm>