alternative to voip gateways

Wed May 6 03:08:01 UTC 2020

Been down that road, not a viable option, in fact i'm told if we get
this done without much drama we'll be converting our existing (much
smaller) wifi sites to copper as well, and since they already have all
this copper laid already, might as well use it

On 5/5/20, Baldur Norddahl <baldur.norddahl at gmail.com> wrote:
> Thinking out of the box, why not implement a WISP setup using wifi? This
> kind of gear is more accessible to normal IT staff.
>
> Voice can be implemented by VoIP using Wifi too.
>
> Regards
> Baldur
>
>
> søn. 3. maj 2020 07.22 skrev Nick Edwards <nick.z.edwards at gmail.com>:
>
>> The huts or cabins whatever you want to call them,  are right behind
>> the admin building at entrance, so first is about 300 meters and the
>> furtherest  is just under 1 mile
>>
>> Cost will be an issue, Im sure I will have no problems if I have to
>> install a full rack of gateways and another full of dslams if it costs
>> 150K, over something 1/5th the size in one rack that will cost 200k -
>> since the company is not charging them for internet or voice.
>>
>> On 5/2/20, Jeremy Austin <jhaustin at gmail.com> wrote:
>> > What’s the average loop length? Grandstream is probably OK to 5+ kfeet
>> but
>> > you will lose CID before that.
>> >
>> > As the low cost option don’t expect them to be trouble-free (or have
>> > particularly good vendor support), but they might work in your
>> application
>> > if cheap is what makes sense.
>> >
>> > My $.02
>> >
>> > Jeremy Austin
>> >
>> > On Fri, May 1, 2020 at 10:11 PM Andrey Slastenov
>> > <a.slastenov at gmail.com>
>> > wrote:
>> >
>> >> Look at MSAN solution. Like Huawei UA5000 or similar solutions from
>> other
>> >> vendors.
>> >>
>> >>
>> >> Regards,
>> >> Andrey
>> >>
>> >> > 2 мая 2020 г., в 07:21, Nick Edwards <nick.z.edwards at gmail.com>
>> >> написал(а):
>> >> >
>> >> > I'm looking at a new sister company we just took over, their remote
>> >> > village has 1700 analogue phone lines to the workers huts, but they
>> >> > go
>> >> > nowhere past the MDF.
>> >> >
>> >> > The office runs voip, now i'm told i have to get phones to the
>> >> > workers
>> >> > because the <lots of explicit words> AKA previous owners of that
>> >> > business  stopped the build when they ran into financial problems.
>> >> >
>> >> > So my plan is to utilize the existing many miles worth of copper
>> pairs.
>> >> >
>> >> > I'm looking at throwing them into Versa Dslams that use pppoe pass
>> >> > through, throw in a mikoTik 1036 as pppoe server, and we got spare
>> >> > R710 i can use as radius server, and by my limited knowledge this
>> >> > works.
>> >> >
>> >> > OK data done, but... now all those pots out lines need to go
>> >> > somewhere
>> >> > that can handle 1700 or more lines, I am looking at either
>> >> > grandstream
>> >> > 48 port FXS gateways or sangoma vega 50 ports (which Ill use as 48
>> >> > so
>> >> > theres a 1:1 match with dslams) the vega 3050 probably wont be used
>> >> > because they are more than twice the price of grandstream.
>> >> >
>> >> > But this all results in a sh1te load of 48 port gateways (power is
>> >> > not
>> >> > a concern), but wondering if there is another solution that is more
>> >> > cost effective? Seems the regular NEC's Siemens and so on might have
>> >> > an option but I can imagine it will be far more expensive than a
>> >> > bunch
>> >> > of individual gateways.
>> >> >
>> >> > This project is in my mind workable, but i've not done such a thing
>> >> > on
>> >> > a large scale.
>> >> > Those who have experience in this field care to chime in? is my
>> >> > method
>> >> > acceptable or not for such a project size?
>> >> >
>> >> > most pbx's I've done are only few hundred analogue lines where
>> >> > gateways are more suited and definitely more cost effective, at all
>> >> > our locations we use freepbx which works perfectly, and we know the
>> >> > beefyness of the box we'll need to install to handle this load,
>> >> > thats
>> >> > not a problem if we go down the gateway method.
>> >> >
>> >> > thoughts?
>> >>
>> > --
>> > Jeremy Austin
>> > jhaustin at gmail.com
>> >
>>
>