alternative to voip gateways

Sun May 10 22:57:59 UTC 2020

Here we have DSL in cabinets so we can have short loop lengths and DSLAMS
that control the entire bundle, to enable vectoring, v35b etc. Since this
scheme does not work if there are multiple DSLAMS on a bundle, only the
ILEC runs the DSLAMS now. I don't know if they just can't (Nokia) or if the
power requirements are infeasible, but they are NOT doing POTS from the
cabinets with DSLAMS. The cabinets have splitters and the POTS is routed
back to the CO where you will have old equipment doing POTS probably dating
30 years or more.

Hence if we want to order a DSL we only pay for the work done at the DSLAM
cabinet and we only pay to rent a port in that DSLAM. If we were to order a
POTS on top of that, we have to pay for them to connect the customer to the
splitter and route him to the CO and then for him to be connected to
equipment there too. This is clearly more work than just connecting him to
the DSLAM and so it is not free. And then we also have to pay to rent a
port on whatever equipment they have at CO.

The FXP solution skips all that and uses a tiny bit of data with QoS and
the voice quality is fantastic. For fiber there is of course no other way,
so why not just do it the same way for all customers? Why pay to rent ports
on the CO installed equipment?

Well even the ILEC figured that out and started to do it that way. Probably
because even for them it is not free to keep running the old equipment at
the CO. That stuff uses power and I heard they also have to pay license
fees.

Also guessing that the reason so many DSL routers have FXP probably means
someone are actually using this stuff.

At 1700 scale it does not really matter how many there are. These things
are going to download the centrally managed config.

The OP is going to buy extra equipment to handle voice. At least that is my
understanding. My question to him was just a humble suggestion that he
could do away with that and just use the for free FXP ports. We have a
whole country here doing that, so trust me it works at scale.

Regards,

Baldur

On Mon, May 11, 2020 at 12:18 AM Mike Hammett <nanog at ics-il.net> wrote:

> From someone that runs a DSL plant with CO-derived dial tone (and
> ATAs\gateways where appropriate), no VoIP is not cheaper and easier at the
> particular density we can infer from the OP.
>
> What's the "lot of equipment" that "simply does not need to be there"? I
> have a DSLAM line card that does DSL only or a DSLAM line card that does
> DSL and POTS. No extra equipment, unless you're counting board-level
> components.
>
> Manage voice configurations on 1700 modems\ATAs or voice configurations on
> 1/48th of that in line cards?
>
> Yes, there are filters required, but I don't see that being a burden.
>
> Any ILEC (in the US anyway) dropping analog voice is attempting to go
> through some regulatory loophole, not because it's a technically superior
> or more cost effective solution.
>
>
>
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> ------------------------------
> *From: *"Baldur Norddahl" <baldur.norddahl at gmail.com>
> *To: *nanog at nanog.org
> *Sent: *Sunday, May 10, 2020 11:54:01 AM
> *Subject: *Re: alternative to voip gateways
>
>
>
> On Sun, May 10, 2020 at 4:16 PM Mike Hammett <nanog at ics-il.net> wrote:
>
>> If POTS last mile is available, why complicate it with VoIP?
>>
>>
> Because it is cheaper and easier? It is a lot of equipment there simply
> does not need to be there. If you have DSL you have CPE equipment and that
> CPE equipment can have FXP out for very little extra. You also save having
> filters to separate DSL and voice.
>
> In any case, even the ILEC here is dropping analog and delivering phone
> services via VoIP and FXP out on the CPE. I believe because the
> technician only needs to go to the DSLAM to connect you. If you are also
> getting analog voice, he needs to go to the CO too because voice and DSLAM
> are no longer cohosted.
>
> Regards,
>
> Baldur
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200511/85daab9d/attachment.html>